少しわかる「システム運用アンチパターン」

Last updated at 2023-12-16Posted at 2023-12-16

はじめに

気になった、というより身に覚えのあるアンチパターンと、その解決策についてまとめます。

「20 分でわかる」系のやつをたくさん書こうと思っていたらめちゃくちゃかぶってしまいました。のでタイトルは「少しわかる」に変えました。

DevOps を支える主要な要素はこの 4 つとされ、それぞれの頭文字を取って CAMS モデルと呼ばれます。
このモデルに沿った改善を行うことでアンチパターンからの脱却ができます。

あるグループの活動が、他のグループの活動に依存し、親子のような関係を成している状態をパターナリスト症候群と呼びます。

この状態では、仕事の進め方やタイミングが常にゲートキーパーと呼ばれる権力者に委ねることになります。

誤操作をしやすいシステムに対する権限管理や、そのときのプロセスでは防げなかった問題に対しての承認プロセスの追加がこの状態を引き起こしています。

結果、ゲートキーパーが生産性のボトルネックとなるばかりか、ゲートキーパーへ多大なプレッシャーが集中することとなります。

「ゲートキーパーによる承認」で解決しようとしていることが何なのかを洗い出し、プロセスの自動化によってこれを解決します。

承認プロセスで軽減しようとしている一般的な懸念には以下のようなものがあります。

チームメンバーが非常に多くの、しかもほとんどは緊急性のないアラートに晒された結果、アラートに対して鈍感になった状態をアラート疲れと呼びます。

オンコールローテーションを編成します。

オンコールローテーションでは、特定の人を一定期間の間システムの最初の連絡先として指定します。問題の発生から各ステージまでにかかる時間についてのサービスレベル目標を設定し、実際の対応時間と比較するのが良いです。

応答時間がサービスレベル目標を上回った場合にはエスカレーションされ、第二のオンコール担当へ連絡が飛ぶようにすると良いでしょう。

オンコール対応への補償、対応の幸福度調査が必要です。
負担を減らすため、一般的なトラブルシューティングタスクは自動化する必要があります。

ドキュメント共有、コミュニケーションの仕組みがうまくいっていないために情報が一部のチームメンバーに溜めこまれている状態を表します。

自分が情報のゲートキーパーになっていないかどうか振り返ってみましょう。また、情報共有の仕組みを作ることや、学習の習慣付けを行うのが良いです。

「ドキュメント化していこう」というアプローチがうまくいかない理由の一つは、あるトピックについての専門的な知識を持ったチームメンバー Subject Matter Experts (SME) が多くないためです。

SME に対して特定トピックの情報や依頼が集中し、情報共有に時間が割けなくなってしまいます。このような場合、以下のような方法で SME から他のメンバーに学習の機会をもたらすことができます。

これら 3 トピックは身に覚えのある方も多いのではないでしょうか。解決策や、アンチパターンの詳細、その他のアンチパターンについては書籍を読んでください。