「システム運用アンチパターン - Forkwell Library #4」でお話しした際の資料となります。 https://forkwell.connpass.com/event/256481/
動画はこちら。 https://youtu.be/hQAeMgXsZWc
30分でわかるシステム運用アンチパターンForkwell Library #42022/08/23田中 裕一
View Slide
田中 裕一GitHub, シニアソリューションズエンジニアオープンソースガイド日本語版Martin Fowlerの記事の日本語化ソースコードブランチ管理のパターンテストにおける非決定性の排除Twitter: @yuichielectricGitHub: @yuichielectric
● 2022/04、オライリー・ジャパンより刊行● “Operations Anti-Patterns: DevOpsSolutions” 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. 開発者は変更をデプロイするためのチケットを少なくとも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
yuichielectric
munetoshi
danilop
manfredsteyer
koic
kishida
mot_techtalk
kinocoboy2
m_seki
rinchsan
syumai
konokenj
honma12345
cherdarchuk
lara
pedronauck
phodgson
davidbonilla
brianwarren
thoeni
roundedbygravity
quramy
marcduiker
nonsquared