記事
チュートリアル
インタラクティブ ガイド
YBIYRI は、どのように常時稼働サービスを可能にしたか
組織で常時稼働サービスをサポートする DevOps 文化を構築する方法
Krishna Sai
IT ソリューションズ担当エンジニアリング部長
常時稼働サービスはアジャイル チームと DevOps チームからの継続的な対応が必要です。これらのチームは単一のインシデントに対応するだけでなく、チームの構造、価値、ツールを緻密に、オペレーショナル エクセレンスが必ずコア コンピテンシーになるようにする必要があります。
常時稼働サービスの課題
14 年前に初めて議論されて以来、YBIYRI は解決までの時間を短縮して運用のベスト プラクティスを拡張することが期待されていますが、現在の開発チームでもそれらはまだ達成できずにいます。残念なことに、依然として多くのチームがそれぞれのスキル、スケジュール、プロセスを、長期的な成功のための基盤ではなくインシデントへの対応策として組み立てています。
チームは十分な準備をせずに YBIYRI 文化に移行することが多く、最初の大きなインシデントは単なる警鐘で終わってしまうことがよくあります。ただし、多くの場合は「インシデントは二度と生じさせられない」という感情が対応のきっかけとなります。対応を実現するために、安全ゲート、チェックポイント、その他の手続き上のオーバーヘッドが導入されています。また、チームの決まりの一部として、変更諮問委員会や毎週のリリース レビューが行われています。すべての変更は停止を防ぐために慎重に精査されます。これによって、たいていインシデントは減少しますが、開発ベロシティと製品の勢いが抑制される可能性があります。この点は、より機敏な競合他社ならはるかに速く対応できるため、競争上の弱点になる可能性があります。
常時稼働サービスのためのチームのベスト プラクティス
関連資料
無料で始める
ソリューションを見る
インシデント管理と対応を合理化
運用準備
YBIYRI チームにとって重大な変化の 1 つに、スプリント計画と実行サイクルの一部として運用準備が含まれるようになったことがあります。運用準備には次があります。
- 開発中に、平均検出時間 (MTTD) と平均分離時間 (MTTI) を最小化する適切で高品質なアラートをコード内に構築する
- 依存するサービスが期待どおりに動作することを保証するためのモニター (適切な場合は統合モニターを含む) を構築する
- 必要なダッシュボードを構築して、それらを使用できるようにチーム メンバーをトレーニングする時間を割り当てる
- オンコール チーム メンバーがスプリント中に他の開発コミットメントを持っていないようにする
- ロールバックが期待どおりに動作することを確認するために、サービスの「大演習」を計画する
- スプリントで帯域幅を計画して、以前のインシデント レビューのアクションをクローズする
- スプリント サイクルの一環として、セキュリティ (アップグレード/パッチ/ローリング資格情報) と運用上の問題に対処する
以上のすべてにおいて、プロダクト所有者は SLO (サービス レベル目標) を理解して、機能の開発と機能性に関連するビジネス上のコミットメントを併せて、適切な優先順位を付ける必要があります。
インシデントの価値を受け入れる
チーム レベルでインシデントの価値を受け入れることで、チームが進む YBIYRI ジャーニーの強力な基盤を構築できます。インシデントの価値は、チームがインシデントに対応する際のガイドになります。これらの価値によって、常時稼働サービスの構築と運用に関する文化を継続するための強力な基盤を確保できます。インシデントの価値は以下を目的としています。
- スタッフとチームがインシデントと事後分析に自主的な意思決定を行えるように導く
- インシデントの特定と管理、インシデントから教訓を得る方法を含む、一貫したチーム文化を構築する
- インシデントの特定、解決、反省の各部分に取り組むべき姿勢をチーム間で一致させる
インシデントの価値プレイブックは、インシデントの対応中にチームの価値を特定して、それらの価値を一貫して実現するための計画を作成するのに役立つ優れたガイドになります。ヘルス モニターで顧客中心主義、チームの結束、共有認識、サービス レベル、またはサービス指示書にチームが取り組んでいる場合は、このプレイブックが役立ちます。
アトラシアンでは、次のインシデントの価値をチーム レベルで採用しています。
心を込めて
バランスを
考えて作る
検出
アトラシアンが顧客より先に把握する
顧客より先にインシデントを検出するための効果的な監視とアラート機能を備えた、バランスの取れたサービス。最高の監視とは、問題がインシデントになる前に警告するものです。
チームで取り組む
対応
躊躇せずにエスカレーションする
インシデントの通知は、たとえ対応が不要だったとしても気にせず行ってください。逆に受けるべきだったインシデントの通知がない場合は問題になります。常に答えがわかるわけではないので「躊躇せずにエスカレーションする」ことを徹底しましょう。
顧客をないがしろにしない
復旧
問題が発生した場合は、迅速に解決する
顧客はサービスが停止した原因は気にしません。気にするのは、どれだけ早くサービスを復旧させられるかです。インシデントの早期解決に全力を尽くすことで、顧客への影響を最小限にできます。
オープンな
企業文化、
デタラメは無し
学ぶ
常に誰も責めない
インシデントは常時稼働サービスの一部です。チームを責めるのではなく、責任を持たせることでサービスを向上させます。
自分自身が変化の原動力になる
改善
同じインシデントを二度と繰り返さない
インシデントの再発を防ぐために根本原因を特定します。具体的な変更事項を具体的な日付までに提供することにコミットします。
常時稼働のエンタープライズ向けツール
常時稼働サービスを実行する企業には、強力なプラクティスと文化に加えて適切なツールが必要です。成熟した DevOps プラクティスがあるチームは、アジャイル プロジェクトの計画とスプリント、CI/CD、自動化、高度な監視とアラート機能を促進するツールを使用します。
Opsgenie のような最先端のインシデント管理ツールによって、優先通知チャンネルに配信される重要なアラートをレイテンシが最も低い状態で確実に受信できます。また、単一のエラーや障害から複数のアラートが生成される場合などで、多数のアラートをフィルタリングしてアラートをグループ化する機能も含まれています。アラート管理ツールは、チームの開発と運用のリズムに自然にフィットするように、チームのツール (ログ管理、クラッシュ レポートなど) とシームレスに統合する必要があります。
チームごとに、ワークフロー、ポリシー、関係者は異なります。アラート管理ツールは、アラートを発信元とペイロードに基づいて処理するために、オンコール スケジュールとルーティング ルールをカスタマイズできる必要があります。多くの場合、アラートはインシデントにエスカレーションする根拠になります。このツールは、インシデント マネージャーを自動で作成して、インシデントの管理に集中します。これによって、コミュニケーション ツールやコラボレーション ツールと統合して、すべての情報が手元にある戦略会議室のようにインシデントを管理できます。最終的に、このツールは高度なレポートとアナリティクスを提供して、成功分野に関する洞察を得て改善の機会を特定する必要があります。アラートの発信元、対応におけるチームのパフォーマンス、オンコール ワークロードの分散方法を明らかにします。
結論
現代の消費者が抱く常時稼働サービスに対する希望は、単なる要望に留まらずニーズが増えています。多くの企業は、こうした要求を満たすために必要な俊敏性を発展させようと YBIYRI の文化を採用しています。問題は、多くの企業がこのベロシティを維持するのに適切なツールと必要なチーム構造/プラクティスを備えていないことです。
チームのために YBIYRI DevOps 文化に移行する予定の場合は、次のステップに従う必要があります。
- アプリケーションまたはサービスの開発と運用のすべてのフェーズを所有できるようにチームを準備する
- スプリント計画で SLO が優先されるように、プロダクト所有者と一致団結する
- インシデントへの対応において、チームの行動をガイドする一連のインシデントの価値を受け入れる
- 信頼性、迅速性、柔軟性を備えた Opsgenie のような最新のアラートおよびインシデント管理ツールをチームに提供する
無料のインシデント管理ハンドブックをダウンロードして、Opsgenie を無料で始めましょう。
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。