30分でわかる システム運用 アンチパターン Forkwell Library #4 2022/08/23 田中 裕一

田中 裕一 GitHub, シニアソリューションズエンジニア オープンソースガイド日本語版 Martin Fowlerの記事の日本語化 ソースコードブランチ管理のパターン テストにおける非決定性の排除 Twitter: @yuichielectric GitHub: @yuichielectric

● 2022/04、オライリー・ジャパンより刊行 ● “Operations Anti-Patterns: DevOps Solutions” Jeffery D. Smith著 (2020/10) ● 運用や開発の一般のエンジニアや チームリーダーがDevOpsによる変革を起こ すための手助け ● 11個のアンチパターンを紹介 ○ ストーリー ○ アンチパターンの説明 ○ 解決策

本書が書かれたきっかけ いろんなイベントで話すようになって気づいたのだけど、ほとんどが ユニコーン企業についての話だった。彼らは利益はあまり気にせず、いかに売上を 増やすかばかり考えている。会社を取り巻く力学が全然違う。 （中略） 本書は、Netflixのような巨人と自分の会社を常に比較するのは危険であるという考えが 発端になっている。インスピレーションを得るには良いかもしれないが、 それは自分たちの問題を解決するとは限らない。他の人の問題を解決するもの でしかないかもしれない。 https://semaphoreci.com/blog/jeff-smith-on-devops-antipatterns から抜粋し日本語訳

1. パターナリスト症候群 2. 盲目状態での運用 3. 情報ではなくデータ 4. 最後の味付けとしての品質 5. アラート疲れ 6. 空の道具箱 7. 業務時間外のデプロイ 8. せっかくのインシデントを無駄にする 9. 情報の溜め込み 10. 命じられた文化 11. 多すぎる尺度

1. パターナリスト症候群 2. 盲目状態での運用 3. 情報ではなくデータ 4. 最後の味付けとしての品質 5. アラート疲れ 6. 空の道具箱 7. 業務時間外のデプロイ 8. せっかくのインシデントを無駄にする 9. 情報の溜め込み 10. 命じられた文化 11. 多すぎる尺度

パターナリスト症候群

パターナリスト症候群 “ある日、ステファニーが社内システムにデプロイをした。デプロイには システム再起動が必要だが、この時間にその社内システムを使っている人は いないとわかっていたので、問題ないはずだった。しかし、今回は急ぎの 作業でそのシステムを使っている人がいた。 デプロイの結果、その人の作業内容が失われてしまい、その人は作業を やり直す羽目になった。 翌日、その人のマネジャーが憤慨し、再発防止を要求。その結果 この会社初の変更管理ポリシーが誕生した。”

導入された変更管理ポリシー 1. 開発者は変更をデプロイするためのチケットを少なくとも3日前に提出。 3日前までに通知されていない場合は１に戻る。 2. 利用部門によるスケジュールを確認。もしデプロイ予定の日にその部門での 作業が予定されている場合は１に戻る。 3. 運用部門による承認。デプロイの前日までに２まで完了している必要があ る。完了していない場合は１に戻る。 4. デプロイの実行。ただし、その際にログインユーザーがいた場合はデプロイ を中止し１に戻る。

何が問題か？ ・デプロイ頻度が多くても週に１回に制限される ・チーム間の余分なコミュニケーションが生じる ・利用者の一人でもログインしっぱなしの場合 　デプロイできない 「システム運用アンチパターン」p.17 図2−１より

達成したいこと： システムの安全性を高める 󰡿な解決策： そのタスクを実行・承認できる人を 少数の人に制限する

パターナリスト症候群 パターナリスト： 親子関係のように、強い立場にある者が弱い立場の者に対して介入すること “パターナリスト症候群では仕事の進め方やタイミングをゲートキーパーと呼 ばれる、権力を持つ人に委ねます。このような権力の集中は、最初は懸命な 判断のように見えますがすぐに生産性の低下を招きます。” (「システム運用アンチパターン」p. 9より) 症状： ・作業の受け渡し ・承認 ・過度なアクセス制限

自動化で解決 待ち時間 ● 変更申請を出してから4日以上待つ 実行時間 ● 人手でスケジュールの確認、デプロイ等 実行頻度 ● 週に一度の変更が限界 実行のばらつき ● 人為的ミス

自動化の考慮事項 承認プロセス ● 何をチェックするか ロギング ● 依頼・承認・実行・結果をどこに記録するか ● 社内のイシュー管理ツールに集約するのがおすすめ 通知 ● 処理が実行されたことをどこで誰に通知するか ● 通知先の管理コストをいかに減らすかが大事 ● 既存のシステム（オンコールシステムとか）があればそれを活用 エラー処理 ● どの程度まで自動復旧を行うか ● 自動復旧よりもエラーを出して人間に判断してもらうので十分な ケースも多い

アラート疲れ

アラート疲れ “レイモンドがオンコール担当していた日の午前4時、データベースの CPU使用率が95％になっているというアラートで起こされた。 調査を開始したが、システムのアクティビティは正常。データベースのログ にエラーも出ていない。１時間ほど寝ずに調査を続けても、おかしな所は 見つからない。そのうちにデータベースのCPU使用率も正常に 戻っていった。 しかし、その次の日も同じアラートで夜中に起こされることになる。”

何が悪いのか ・オンコールを担当するエンジニアの健康を損なう ・アラートが無視されたり、応答が遅れたりするようになる

良いアラート ● 行動可能である ○ システムメトリクスによるアラートは行動可能でない 場合が多い ○ 受け取った時に取るべき手順(runbook) ○ なぜ通知する必要のあるアラートなのか ● タイムリーである ○ 待てば解消されるかもしれない事象をアラートする のはやめる ● 適切に優先順位づけされている ○ 全てのアラートが誰かを呼び出す必要はない

カスタムメトリクス ユーザー/ビジネスの観点でシステムが正常に動作しているかどうかを 知るためのメトリクス ● スループット ● エラー率 ● レイテンシ 開発・運用・プロダクトチームの協力が必要

故障モード影響分析 エラーが発生する可能性のある箇所を洗い出し、以下の軸を1〜10で スコアづけ - 深刻度　　　（1：深刻でない　　〜　10：深刻） - 発生頻度　　（1：ほぼ発生しない〜　10：頻繁に発生する） - 検出可能性　（1：検出が容易　　〜　10：検出不可能） これら3つのスコアを掛け合わせて値が高いものから優先

アラートの計測 ● ノイズ率 ● オンコール幸福度 ○ 誰がアラートを受けているか ○ どの程度の緊急度か ○ どのように通知されているか ○ いつ受けているか

● 11あるアンチパターンのうちの2つを 紹介しました。 ● ほかのパターンを知りたい方は ぜひ本書を手にとっていただけると 嬉しいです。 ● シナリオがあるあるだと思うので、 社内勉強会で使って、改善に向けた仲間を 集めるのにも使えるかも。 まとめ

https://note.com/yuichielectric/n/n45b907b9dd93