実行中の CheckOps
Compass では、CheckOps を直接実行できます。Compass には、チームが 1 か所で指標や目標を簡単に確認し、実行する予定のアクションを書き留めておく場所があります。
指標、アラート、計画したアクションを含む週次 CheckOps レポートのサンプル。
Trello で週ごとに CheckOps レポートを実行することもできます。
前提条件
対面
Compass での CheckOps レポート・テンプレート
ホワイトボード
マーカー
付箋紙
タイマー
オプションのテンプレート
アトラシアンテンプレート
このプレイは、Compass の CheckOps 機能を使うと最も効果的です（チームが CheckOps を使い始める方法をご覧ください）。Compass を使い始めていなくても、Trello で今すぐチームの健全性を追跡し始めることができます。
このプレイを実行するための手順説明
このプレイは、ソフトウェアの開発、デリバリー、実行を担当するチーム向けに設計されています。
1. 実践の準備を整える 30 分
DevOps チームの目標を設定する
チーム全体で共通の目標を設定します。
- Compass にログインして CheckOps 機能に移動するか、別の方法を準備して目標を追跡します。
- 開発または運用のプラクティスについて、何を変更または改善したいかを特定します。
ビジネス要件が運用目標の指針になります。
- 顧客に最速でサービスを提供する、あるいは年中無休で稼働する必要がある場合、レイテンシー、スループット、または可用性に関する DevOps の目標を設定します。
運用目標はチームからも得られます。
- チーム・メンバーが夜、数時間おきにアラートやインシデントに起こされながらも何も対処できず、うんざりしている場合、インシデントや対処不可能なアラートの数を最小限に抑えるための目標を設定します。
- プル・リクエストのレビュー待ちの時間が長すぎると思われる場合、プル・リクエストを未処理のままにできる期間について、運用上の目標を設定します。
DevOps 目標は少しずつ設定してください。シンプルに保ち、進捗状況の追跡に適した情報を確実に収集できるようにします。できれば、すべてのサービスで同じ目標を設定します。そうすれば、チームが各ミーティングでレビューするデータに集中しやすくなります。
DevOps の目標が測定可能であることを確認する
達成したかどうかを明確に判断できるように、測定可能な方法で目標を定義します。
- そのためには、サービスの運用上の指標が役立ちます。監視ツール（Splunk Observability、DataDog、Grafana など）を使用して、影響を与えたい指標を明示的に記述します。
- リポジトリの開発指標も重要なものです。この追跡には、Jira Software や Compass が最も適しています。
この演習を進めていくと、自分が実際に改善しようとしているものが測定されていないことに気付くかもしれませんが、問題ありません。最初の CheckOps ミーティングのアクション・アイテムの 1 つとして、関連する DevOps 指標が追加されることがあります。それが完了したら、今後のミーティングで明らかにできます。
DevOps 目標を書き留める
設定した目標に対してチームが同意したら、それを書き留めて全員で共有します。これが運用上の目標の宣言になります。次に、視認性が高く、アクセスが簡単な基本の Confluence ドキュメントを設定し、そこに DevOps 目標を保存します。Compass を利用している場合は、スコアカードに目標を設定できます。
DevOps の目標は、時間の経過とともに変化する可能性（および必要性）があります。情報の収集が進むと、目標についてより多くの情報に基づいた意思決定ができるようになり、また、ビジネスや運用上の目標が進化していく可能性もあります。ただし、一度に目標や DevOps 指標を追加しすぎると、チームの集中力が途切れ、望ましい結果を達成できなくなることがあるため注意が必要です。多くても、3 か月から 6 か月の間に設定する目標は 3 つまでにしておくことをお勧めします。
チームが選ぶ可能性のある目標の例としては、次のものがあります。
- プル・リクエストまたは TCT（総サイクル期間）の増加：チームが締め切りを守れないことが多い場合に役立ちます。
- チームが毎週報告するアラートやインシデントの数の削減：チームの業務が頻繁に中断される場合に役立ちます。
- デプロイ頻度の低下：チームが受け取るインシデントが多すぎる場合に役立ちます。
チームの健全性が向上すると、準備段階が短くなることがあります。
2. データを収集する 15 分
チームの目標が設定されたら、プレゼンターがデータを収集する必要があります。ステップ 1 を毎週実行する必要はありませんが、データは毎週収集しなければなりません。
ログを取る
ある CheckOps ミーティングから次のミーティングまでの間に、ツールでキャプチャできない注目すべきイベントが発生するとします。人間の記憶は間違いやすいことを考えると、次のミーティングで対処できるように、このようなイベントの詳細を書き留めておく必要があります。
リモート・チームに所属している場合は、注目すべきイベントを追加できる新しい CheckOps レポートを毎週作成し、該当するチーム・メンバーと共有します。アトラシアンの DevEx プラットフォームである Compass を使用している場合は、健全性の詳細ページから CheckOps の実践を迅速かつ簡単に開始できます。
- オンコールが呼び出され、アラートが誤検知だったことがわかった場合、確実にチームの開発者エクスペリエンスに影響するため、これを書き留めてグループと共有し、今後の改善に努めます。
- インシデント、デプロイ失敗、あるいはプル・リクエストによってマージに時間がかかりすぎた場合、チームが後で記憶を頼りにイベントを再構築する必要がないように、その週の簡単なメモを取ります。
レビューの準備を整える
オンコール・ローテーションが終了したら（または終了後しばらくしてから）、プレゼンターはそのローテーションの CheckOps レポートを作成する必要があります。端的に言うと、レポートに以下を含める必要があります。
- CheckOps を実行するサービス/コンポーネントのリスト。
- それぞれのコンポーネントの（目標に対する）測定値。
- 目標が達成されたかどうかを示すチェック（チェックマーク）または X（十字）。
- 達成されていない目標に対する緩和計画、および目標が達成されなかった理由についてのプレゼンターからのメモ。
- フォローアップ・アクションを記録するためのセクション。
- その他のイベントや異常の要約。
フォローアップ・アクションが CheckOps レポートに記録されることが重要です。記録できない場合、改善を促すフィードバック・ループが必要なときにステータスを報告することになります。
3. CheckOps レビュー・ミーティングを実施する 30 分
全員がそれぞれの役割を果たす
常にインタラクティブであるようにします。オンコールを担当する DevOps チーム全員がこのミーティングに出席し、全員が次を担当します。
- プレゼンター：オンコールローテーションの終了時点で、CheckOps レポートとその結果を提示しなければなりません。オンコール業務がない場合は、その週に行われるイベントについてメモを取り、その結果をプレイの途中で発表できる人を指名します。
- 次のオンコール：この人は、これまでに見つかった課題や、次のオンコール・ローテーションで再発する可能性のあるリスク領域など、プレゼンターの観察に細心の注意を払います。
- リーダー：リーダーとは、チームがアクションに優先順位を付け、確実にフォローアップするのをサポートする人です。フォローアップが必要なアクションが発生した場合、リーダーは、適切な人がアクションを担当し、解決まで見通せるようにサポートする必要があります。
- その他のオンコール・チーム・メンバーとコンポーネント・オーナー：これは、オンコール・ローテーションに参加している、または運用されているサービスやコンポーネントに精通している人です。
結果を共有して議論する
プレゼンターは、各サービス/コンポーネントについてチームに説明し、目標が達成されたかどうか、およびその理由を共有します。特定のサービスで発生した運用上のイベントや異常について議論し、観察結果と分析を共有します。チーム・メンバーの仕事は、質問してフォローアップ・アクションを提案することです。
DevOps チームのすべてのサービス/コンポーネントがそれぞれの目標をどのように達成できるかついて、協力して調べます。これはチーム全体の課題です。
各チーム・メンバーがとるべきアクションを書き留め、ミーティング中にバックログでチケットを作成します。
ヒント：リアクティブではなく、プロアクティブに行動する
運用目標や開発目標の達成についてチームに責任がある場合、その行動はリアクティブになりがちです。信頼性、デリバリー・スピード、コード品質のいずれであっても、CheckOps が推進するデータ主導のアプローチなら、チームが DevOps 目標を達成し、開発者のエクスペリエンスを向上させ、継続的な改善を実現できるようになります。
フォローアップ
イテレーション
CheckOps プレイをチームのオンコール・スケジュールの引き継ぎに合わせて毎週実施することをお勧めします。ステップ 2 と 3 は毎週繰り返されますが、ステップ 1 は毎週必要になるとは限りません。プレイを何度も実施すると、ステップ 1 と 2 の時間が短くなります。CheckOps プレイを数週間続けると、チームが他の重点領域にも実践の範囲を広げ、発展させていく機会が生じることもあります。たとえば、コード・カバレッジなどの品質指標、特定機能の週間アクティブ・ユーザー数などのビジネス指標、あるいはチームの健全性を高めるためのものを測定することができます。
運用目標を再評価する
時間が経つにつれて、設定した当初の DevOps 目標がチームのニーズを満たさなくなる場合があります。たとえば、ビジネス・ニーズが変わったり、目標がより意欲的なものになったりした場合などです。その場合は、ステップ 1 を実行して、定められた運用目標を更新して、プラクティスを続行します。また、必要に応じて、CheckOps プラクティスのスコープを拡大して、より多くのサービスやコンポーネント、または運用プラクティスの他の側面をカバーすることもできます。
レポートを自動化する
スコープが拡大するにつれ、レポートに費やす時間を減らし、分析に時間をかける必要が生じてきます。主要な指標の収集と CheckOps レポートの生成を自動化する方法を探しましょう。これによってレポート作成の作業が自動化されれば、チームの生産性と開発者のエクスペリエンスの両方が向上します。
自動化を追加する場合、収集するデータの分析と CheckOps ミーティングの準備には引き続き十分な時間をかけます。アトラシアン社員はこのために Compass 指標を使用しています。また、CheckOps エクスペリエンスを製品に統合し、お客様も利用できるようにしています。
運用目標の例
振り返り
ここでは、チーム・メンバーがそのチームの責任に応じて、CheckOps のプラクティスを構築する運用目標の例をいくつか紹介します。
Delivery types | Possible objectives |
|---|---|
Microservice |
|
On-call team |
|
Software delivery |
|
Mobile application |
|
私たちのチームからあなたのチームへ
ニュースレターで最新のプレイ、ヒント、コツについて最新情報を入手できます。
