はじめに
気になった、というより身に覚えのあるアンチパターンと、その解決策についてまとめます。
「20 分でわかる」系のやつをたくさん書こうと思っていたらめちゃくちゃかぶってしまいました。のでタイトルは「少しわかる」に変えました。
まず最初に、DevOps の 4 つの柱
-
文化 (culture)
チームが活動する際の基準になるもの -
自動化 (automation)
メンバーを平凡な作業から解放するもの -
メトリクス (metrics)
物事がうまくいっているかどうかを監視するもの -
共有 (share)
文化を強化するもの
DevOps を支える主要な要素はこの 4 つとされ、それぞれの頭文字を取って CAMS モデルと呼ばれます。
このモデルに沿った改善を行うことでアンチパターンからの脱却ができます。
パターナリスト症候群
あるグループの活動が、他のグループの活動に依存し、親子のような関係を成している状態をパターナリスト症候群と呼びます。
この状態では、仕事の進め方やタイミングが常にゲートキーパーと呼ばれる権力者に委ねることになります。
誤操作をしやすいシステムに対する権限管理や、そのときのプロセスでは防げなかった問題に対しての承認プロセスの追加がこの状態を引き起こしています。
結果、ゲートキーパーが生産性のボトルネックとなるばかりか、ゲートキーパーへ多大なプレッシャーが集中することとなります。
解決策
「ゲートキーパーによる承認」で解決しようとしていることが何なのかを洗い出し、プロセスの自動化によってこれを解決します。
承認プロセスで解決したいこと
承認プロセスで軽減しようとしている一般的な懸念には以下のようなものがあります。
- プロセスの全ての作業が継続されるべき状態にあるかを確認したい
- 作業の発生を知らなくてはならない人に知らせておきたい
- 並行する他のプロセスとの衝突がないことを確認したい
- 変更のリスクが許容できるものかを確認しておきたい
アラート疲れ
チームメンバーが非常に多くの、しかもほとんどは緊急性のないアラートに晒された結果、アラートに対して鈍感になった状態をアラート疲れと呼びます。
解決策
オンコールローテーションを編成します。
オンコールローテーションでは、特定の人を一定期間の間システムの最初の連絡先として指定します。問題の発生から各ステージまでにかかる時間についてのサービスレベル目標を設定し、実際の対応時間と比較するのが良いです。
3 つのサービスレベル目標
応答時間がサービスレベル目標を上回った場合にはエスカレーションされ、第二のオンコール担当へ連絡が飛ぶようにすると良いでしょう。
- 問題の発生から確認までの時間
- 確認から対応開始までの時間
- 対応開始から完了までの時間
オンコール対応の負担
オンコール対応への補償、対応の幸福度調査が必要です。
負担を減らすため、一般的なトラブルシューティングタスクは自動化する必要があります。
情報のため込み
ドキュメント共有、コミュニケーションの仕組みがうまくいっていないために情報が一部のチームメンバーに溜めこまれている状態を表します。
解決策
自分が情報のゲートキーパーになっていないかどうか振り返ってみましょう。また、情報共有の仕組みを作ることや、学習の習慣付けを行うのが良いです。
学習の習慣付け
「ドキュメント化していこう」というアプローチがうまくいかない理由の一つは、あるトピックについての専門的な知識を持ったチームメンバー Subject Matter Experts (SME) が多くないためです。
SME に対して特定トピックの情報や依頼が集中し、情報共有に時間が割けなくなってしまいます。このような場合、以下のような方法で SME から他のメンバーに学習の機会をもたらすことができます。
- ランチ & ラーン
- LT
- ブログでの、敷居を下げた共有
おわり
これら 3 トピックは身に覚えのある方も多いのではないでしょうか。解決策や、アンチパターンの詳細、その他のアンチパターンについては書籍を読んでください。