はじめに
自分が経験したなかで、運用体制が整っていないWebサービスがあり、インシデントが発生した際は各メンバーが場当たり的に対応しているものがありました。
顧客と結んだSLAもなく、ベストエフォートで運用されていました。
こんなWebサービスの運用改善を任された場合に、どのような手段で改善していけばよいのでしょうか。
自らの業務内で調査した結果、いくつかの運用改善事例を集めることができました。
この記事ではそれらの事例を紹介していきます。
運用改善事例紹介
SLOの設定
SLAが設定されていないプロジェクトでは、ベストエフォートでサービス運用していきます。
この場合、運用改善の目的も曖昧なものになってしまうことが往々にしてあります。
目標がないからです。
SLAがなければ、組織内でSLO(Service Level Objective)を設定しましょう。
Google Cloudの記事でも、SLOの重要性が説かれています。
SLOの設定値の例を一部紹介します。
稼働時間 /（稼働時間 + 停止時間）や、成功したリクエスト数 /（成功したリクエスト数 + 失敗したリクエスト数）という数式で可用性を計測できます。どの単位を使用するかにかかわらず、計測の結果は 99.9 % や 99.999 % といった割合で示され、これをスリー ナイン、ファイブ ナインと呼ぶこともあります。
https://cloud.google.com/blog/ja/products/gcp/available-or-not-that-is-the-question-cre-life-lessons
アラート内容を工夫する
上記の記事で紹介されていたのは、アラート内容を工夫するということです。
あるメトリクスが、しきい値を超過した場合にSlackへアラートを送信するプロジェクトは多いと思います。
このアラートの内容をデフォルトのまま使用していると、アラートの内容が簡潔に記されただけのものが届きます。
これでは、初期対応が若干遅れてしまいます。
よりリッチな内容をアラートの中身に含めることで、初期対応を少しでも早くしましょう。
具体的には、下記のような情報を盛り込む案が紹介されていました。
・障害対応手順
https://nasrinjp1.hatenablog.com/entry/2019/05/31/114838
・運用ドキュメントへのリンク
・復旧目標時間
ペアオペ・モブオペ
突撃！隣のDevOps 【はてな編】
https://dev.classmethod.jp/devops/dev-ops-hatena/
上記記事のなかでは、ペアプロならぬペアオペが紹介されていました。
詳細な説明はありませんでしたが、弊社内でも導入することになりました。
たとえば、いつも同じメンバーがアラート対応にあたっているとします。
そのような場合、次回アラートが上がった際には、そのメンバの作業内容を周りの人が眺めて運用ドキュメントに起こすということをします。
結果、アラート対応知識の属人化を低減することができました。
そのメンバの業務負荷も減り、チーム内のコミュニケーションも増えました。
ポストモーテムの実施
ポストモーテムとは
SRE本のなかで紹介されている概念です。
単語の詳しい説明は下記記事を参照ください。
簡単に説明すると、なにか問題が発生後、解説したあとに行う振り返り作業のことです。
チームで問題が発生した理由を分析し、同じ失敗を繰り返さないための手立てを考えドキュメントにまとめます。
ポストモーテムを開催する目的は、失敗から学ぶことです。
そのためには、個人に対する批判を行ってはいけません。
障害報告書との違いは、ポストモーテムによるドキュメントがあくまで社内向けだということです。
次第にポストモーテムが蓄積、解析することで、今後改善すべきテーマや領域が発見できます。
また、弊社内では定期的に監視ツールのダッシュボードを観察する会を実施しています。
意識していないと、アラートが上がった際だけダッシュボードを確認することになりがちだったためです。
2週に一度、ダッシュボードを眺めてアラートを削除したり監視対象を追加したりする話し合いを設定しています。
カジュアル勉強会
突撃！隣のDevOps 【GMOペパボ編】
https://dev.classmethod.jp/devops/dev-ops-gmo-pepabo/
上記記事では、すぐ実施する勉強会が紹介されていました。
個人が持っている情報をみんなに共有する時間を設けるようにし、聞きたいことがある人に尋ねると、
https://dev.classmethod.jp/devops/dev-ops-gmo-pepabo/
「では今から勉強会をやりましょう」
このように、勉強会はすぐやる、ホワイトボードを写真にとって書き起こし、
勉強会というと、前準備をして実施するイメージがありました。
この事例の場合だと、準備のいらないカジュアル勉強会を積極的に実施することで、メンバー間の知識共有が活発に行われているようでした。
おわりに
運用改善のために調査した事例をまとめてみました。
みなさんも、運用業務について考える機会があれば、是非参考にしてみてください。
コメント