ベロシティの高いチームのためのインシデント管理
「構築した者が運用する」というアプローチは宣伝文句通りなのか?
「構築した者が運用する」という考え方が13年前に広まりました。この考え方は、期待されていた結果をもたらしたのでしょうか。
今から 13 年前、ソフトウェアを導入/運用するための新たなスローガンがあるインタビューで提唱され、世界中の IT プロセスを根底から覆しました。今日では、これまでにないほど多くのビジネスが DevOps のコラボレーション アプローチとそれに伴う「構築した者が運用する」という考え方を採用しています。しかし、10 年以上が経過し変化を遂げた現在でも、このコンセプトは有効なのでしょうか? このコンセプトは、期待されていた利益をもたらしたのでしょうか?
変化の歴史
すべては 2006 年、Amazon CTO の Werner Vogels 氏のインタビューから始まりました。
「開発者に運用上の責任を持たせることで、顧客と技術の両方の観点からサービスの品質が大幅に向上されました。従来のモデルでは開発と運用には壁があり、開発したソフトウェアを運用側に投げ渡してその後は関係ないという考えでした。しかし、Amazon では違います。構築した者が運用するのです。これによって、開発者は自分のソフトウェアの日常的な運用に触れられます。また、開発者は日々、顧客と接することになります。顧客からのフィードバックのループが、サービスの品質向上には欠かせないのです」
そこから、「構築した者が運用する」が始まりました。これは、その後のコラボレーション DevOps ムーブメントの高まりとうまく融合した新しいやり方で、ソフトウェアを構築する人と運用をサポートする人の間の壁を取り払うことが最重要視されました。
このアイデアが軌道に乗ったのには、理由がありました。開発と運用の間のギャップを埋めることは非常に理にかなっています。コードを書いたチーム、つまり製品に精通しているチームが、インシデント発生時にスーパー ヒーローのように振る舞うべきではないでしょうか? この方法は、解決までの時間を短縮するだけではありません。開発者は顧客からのフィードバックやリアルタイムの課題を身近に感じて、常時稼働サービスを促進できるようになります。
明確なメリット...そして明確な課題
すべてのプロセスの移行と同様に、これにはメリットだけではなく一連の課題が発生しました。また、伝統的な構造を持つビジネスからは多くの抵抗がありました。
メリットとしては、IT チームへのプレッシャーが軽減されたこと、本番環境に対応できる設計であること、応答時間が短縮されたこと、より徹底的にテストされたコード (結局のところ、バグを解決するために自分が午前 1 時に呼び出されるくらいなら、次のデプロイをダブルチェックする可能性が高くなります) であることなどが挙げられます。また、新しいスキルを習得して新しい方法でビジネスを考えることで、開発者はより良くよりバランスの取れた開発者になれました。
コードに対する責任は同じチームが負うため、このアプローチはインシデント防止にもプラスの影響を与えます。あるレポートでは、デプロイ前に外部のチームによってコード レビューを行った企業と、コード レビューをまったく行わなかった企業を比較したところ、成功率が同じであることがわかりました。一方、ピア レビューは、製品を熟知している開発者によって実施されて、インシデント防止に好影響を与えました。
課題に目を向けると、私たちのチームは、インシデント管理のアプローチを移行することによる次のような課題に対処しました。すなわち、[インシデント管理の分散化] の課題は、組織にはまだある程度の一元化が必要であるということです。リーダーは、レポートやドキュメントにアクセスする必要があります。ビジネス関係者は更新情報を求めています。平均解決時間や平均確認時間などのインシデント指標を確認したいと考えています。明確なインシデントの更新情報、インシデント事後分析レポート、修復作業を期待しています。
分散化 [と「構築した者が運用する」アプローチ] への移行が順調に進行している多くの企業にとって、この課題に対する答えは、分散化とチームの自律性によってインシデントを迅速に解決して情報を一元化し、ビジネスで常に最新情報を共有できるテクノロジーです。
もう 1 つの重要な課題として、多くの企業にとって「構築した者が運用する」ということは、チームの構造や社内の文化を変えることを意味します。これには、コラボレーションに対する開放性、製品に対する新しい考え方、コミュニケーションの障壁を打ち破る新しいチーム構造が必要です。これらのような変化は困難であり、成功するためにはかなり具体的なアプローチが必要になります。
「構築した者が運用する」というアプローチは成功しているのか?
課題はあるものの、私たちの経験では答えはイエスです。「構築した者が運用する」というアプローチは依然として業界を変革し続けており、従来の IT チームでさえこのアプローチのテストにゆっくりながらも取り組んでいます。
「構築した者が運用する」というアプローチの導入に関する研究事例はありませんが、私たちの経験では DevOps の原則全般の導入に伴ってこのアプローチが導入されるケースが多くあります。その証拠となる数値もあります。Forrester のレポートによると、2017 年には 63% の組織が DevOps を導入したと回答しています。また、27% の組織が 1 年以内に DevOps の導入を予定しています。変更に関心がないと回答したのはわずか 1% でした。
より説得力のある企業では、DevOps 原則を採用すると、顧客満足度が平均 45% 向上して従業員の生産性が 43% 向上したことが報告されています。
「構築した者が運用する」アプローチを開始する
「構築した者が運用する」というアプローチの採用は、柔軟で高度にコラボレーティブなプラットフォームがなくては不可能です。開発と運用がシームレスに連携できることが大前提です。このタイプのコラボレーションは、適切なツールを利用することによってのみ実現できます。
Jira Service Management では、統合された協調的なコミュニケーションによってチームが結びつき、チャット チャンネル (Slack、Microsoft Teams) からビデオ会議 (ネイティブ ビデオ ブリッジまたは Zoom を介して) まで、チームが好みのコミュニケーション方法でつながることができます。アラートからルーティング ルールなどに至るまで、Jira Service Management のほぼすべての要素をあらゆるチームのニーズに合わせてカスタマイズし、初期対応段階から事後分析レポートや問題管理まで、必要な対応者に最新の情報を伝え、すべての関係者にコンテキストを提供できます。
Jira Service Management がチームのコラボレーションの可能性を解き放つ方法をご確認ください。
Opsgenie を使用したオンコール スケジュールの設定
このチュートリアルでは、オンコール スケジュールの設定、オーバーライド ルールの適用、オンコール通知の設定などの方法を学習します。すべて Opsgenie 内で行います。
このチュートリアルを読む