ベロシティの高いチーム向けの ITSM
DevOps のアプローチで IT サポートを実行する方法
DevOps の原則を IT サービス チームとエンジニアリング チームに適用することで、サービスの品質、チームの士気、問題解決能力、ビジネスの生産性が大幅に向上されることが実証されています。実際、DevOps の原則を採用している企業は、顧客満足度が平均で 45% 高く、従業員の生産性が 43% 向上し、欠陥率が 41% 改善され、IT 関連コストが 38% 削減されていると報告されています。
このような統計では、DevOps の原則を IT サービス管理に統合することは、企業にとって大きな勝利を収めることと同義です。しかしそれはまた、チームにとっては複雑な変化のように聞こえるかもしれません。一方で良い点はというと、これは見た目ほど複雑ではありません。よりパフォーマンスの高いサービスへの鍵はとてもシンプルで、却って驚かせてしまうかもしれません。
DevOps とは何か?
では、DevOps とは具体的に何でしょうか?これは、開発と運用という、長きにわたって衝突してきた、サイロ化されている場合が多い 2 つのチームをまとめる一連のプラクティスです。目標は、コラボレーション、オープンなコミュニケーション、そして両部門がそれぞれの目標を達成するための方法を見つけることです。
当社のエキスパートの説明: 「DevOps はソフトウェア開発チームと IT チーム間のプロセスを自動化するプラクティスを 1 つにまとめたものであり、より短時間で、そして信頼性の高い形で、ソフトウェアの構築、テスト、リリースを可能にします。DevOps のコンセプトの根底にあるのが、これまでそれぞれのサイロの中で仕事をしていたチームの間でコラボレーションを行う文化を形成することです。DevOps によってもたらされるメリットとして、信頼の向上、ソフトウェア リリースの迅速化、重要な問題の素早い解決、計画外の作業をスムーズに管理できる力などがあります」
DevOps が IT サポートを受ける理由
ビジネスの観点からは、その数字が物語っています。45% の顧客満足度向上、43% の従業員生産性向上、38% の IT 関連コスト削減。DevOps ムーブメントは、ビジネスの収益を大幅に向上してきました。これこそ、5 社のうち 4 社は DevOps の原則を多かれ少なかれ使用しているといわれている理由です。
うまくできた場合はチーム自身にも同様に説得力のある DevOps は、従業員とチームの満足度、コラボレーション、認知度を向上させます。大まかなプロセスをスムースにしてタスクを促進させ、IT、開発、その他の相互に関連するチーム間で長きにわたって緊張を引き起こしてきた構造の層を取り除きます。
何も知らされていない新しいリリースをサポートする準備を整えられないことに運用チームが悩まされて続けてきた (Gartner によると、インシデントの 85 ～ 87% の原因) 場面では、DevOps はコミュニケーションを開いて今後の状況に備えて IT 運用を準備します。開発チームがローンチを遅らせる運用のプッシュバックに不満を抱いていた場面では、現在はチームはローンチを早めるために協力して、SLA の約束や SLO の目標を危険に晒しません。
IT サービス向け DevOps: ベスト プラクティス
文化的な変化に優先順位を付ける
DevOps 統合の最大の課題は、文化的な転換です。
従来の IT 組織は往々にしてサイロ化しているため、開発チームは独自のエコシステム内で作業して運用部門が運用を引き継いでいます。変更が開始されると、これも往々にして警告されないままシステム変更が行われる場合があります。
一方でDevOps 組織は、(ハック デイ、スタンドアップ、チャット ルームなどのプラクティスとツールを通じて) コラボレーションとチーム間のコミュニケーションを優先します。
この変化を受け入れることは、新しいツール、プロセス、文化的視点を受け入れて、チーム間のコミュニケーションと成功の共有を優先させることを意味します。
できる場所を自動化
DevOps の生産性の向上について、その少なくとも一部は自動化を優先する理念によるものです。DevOps を採用することは、チーム間で常にどこを自動化できるかについて尋ね合うことを意味します。
一般的なエラーのコード レビューを自動化できますか? システムを自動化して、問題、インシデント、リクエストをそれらを引き起こす原因となった可能性のある変更やリリースに関連付けられますか? セキュリティや法的要件を満たさないコードのリリースを防ぐために、チェックとバランスを自動化できますか? SLO 目標に危険なほど近い場合はシステムを自動化して新しいリリースを凍結できますか?
多数ある DevOps 指標を自動化して改善する方法の中で、最も一般的な 3 つの方法は次のとおりです。
- ワークフロー (例: サービス デスクを通してサポート チケットの転送を高速化できます)
- ナレッジ (インシデントが発生したら、サービス管理ツールが関連するナレッジとドキュメントを自動的に表示するはずです)
- エスカレーション (組織内に問題を解決できる担当者が 2 人しかいない場合、スマート システムは厳格で直線的なエスカレーション パスに従うのではなく、問題を直接彼らにエスカレーションするはずです)
重要な指標を追跡する
開発業務と IT 運用が連携しながら、優れたプラクティスによってどのように進捗状況を追跡するかも指示されます。
一般的な DevOps 主要業績指標 (KPI) には、MTBF (平均故障間隔)、MTTR (平均復旧、修理、応答、または解決時間)、MTTF (平均故障時間)、MTTA (平均確認時間) が含まれます。また多くの企業も、特定の期間内に生成されたアラートやリクエストの数、1 分あたりのダウンタイムにかかるコスト、または呼び出し/リクエストあたりのサポート費用などの数字を参考しています。
チームが追跡する必要がある指標は、チーム自体、SLA 契約における顧客への約束、組織と合意した SLO 目標、対象とする特定のトラブル スポットによって異なります。また、指標は可変要素であることを認識することも重要です。IT 部門がサポートしている製品から関係者のニーズ、外部の法的義務やセキュリティ上の義務に至るまで、社内で物事が変化すると、追跡する指標とどのように追跡するかも変化する必要があります。
共有に優先順位を付ける
DevOps とは、作成とメンテナンス、作成者とサポーターとのギャップを解消すること、共有されるビュー、目標、プロセス、語彙を作成すること、ナレッジとコミュニケーションを共有すること、ツールセット、リソース、コードベースを共有すること、そして、おそらく最も重要なこととして、所有権を共有すること、つまりは責任と成功の共有です。
多くの従来の組織にとって DevOps への移行は、これらの責任と成功の共有をどのように定義、褒賞、追跡するかを再考することを意味します。開発チームと運用チームの目標が一致していませんか? あるチームの成功によって他のチームの成功が難しくなりませんか?
たとえば、開発チームができる限り迅速に新機能を開始して、IT 運用チームがアップタイムの維持を任務とする場合、これらの 2 つの目標は互いに悪影響を及ぼす可能性があります。運用はアップタイムの目標を超えるために開発者を遅らせたい場合があり、開発はローンチ目標の達成を妨げていることに対して運用を不快に思う場合があります。
多くの DevOps チームのソリューションは、SRE アプローチです。アップタイムが SLO 目標の範囲内にある限り、開発チームは思うがままに開始できます。アップタイムが許容できないレベルまで落ち込むと、チームが協力してアップタイムを必要な水準に戻すまで、すべてのローンチがフリーズします。
ITIL 対 DevOps
ITIL に従うと、おそらく DevOps がどこに収まるか疑問に思うでしょう。多くの企業にとって、ITIL と DevOps の各プラクティスは連携して機能します。実際 Atlassian では、多くの企業が両方の効用と強みを取り入れていることを確認しています。
この DevOps と ITIL の比較が示しているように、「実際には両方が必要です。今話しているのは競合する箱についてではなく、互いに捕捉し合う箱についてです。私たちはよりスマートにより迅速に仕事をできるようにする必要がありますが、プロセスと制御も依然として必要です。最新の優秀なチームや組織はこうしたことに気付き始めていて、両方の要素を取り入れるようになっています。彼らは既に、「二者択一」の最後通告を乗り越えたのです」
ITIL は、運用、サポート、ガバナンス、その他の主なビジネス機能のベスト プラクティスに対処する傾向があります。DevOps では、継続的なデリバリー、誰も責めることのない文化、コラボレーション ツール、アジャイル プラクティスなど、ITIL ガイドラインに長く組み込まれているプラクティスを強化して、そのプラクティスを基盤とするものを提示します。
DevOps 指向の組織向けツール
DevOps アプローチを採用することは、コミュニケーション、自動化、チーム間のコラボレーションのための新しいツールを採用することも意味する場合もあります。
新しいツールを評価する際には、次のような質問をすることが重要です。
- このツールは当社の環境で動作して、既存のツールと統合していますか?
- 私たちのニーズを満たしていますか?
- すべての新しいツールは、包括的でまとまったツールセットで連携していますか?
ひいき目もあるかもしれませんが、アトラシアンでは IT サービス管理には Jira Service Management を、ソフトウェア開発には Jira Software を、コード リポジトリには Bitbucket を使用しています。
これらのツールが極めて有効に機能する理由の一つは、ツールが有効に連携しているためです。また、チームの構造内のサイロから離れているときは、どのツールを選択してもサイロから離れたいと思うでしょう。
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
ホワイトペーパーを読むAtlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
ホワイトペーパーを読む