【技術本】システム運用アンチパターン
【技術本】システム運用アンチパターン
https://amzn.to/4kGE2hR
【技術本】システム運用アンチパターン
へポスト
以下のDevOpsにおける１１のアンチパターンを取り扱っている。
・パターナリスト症候群：チームをより効果的にする意図で作られたものが、むしろチームを停滞させてしまう。
・盲目状態での運用：システムは、役に立つメトリクスは収集されておらず、パフォーマンスについて正しく答えられていない状態。
・情報ではなくデータ：整理されていない生の事実に過ぎないデータのみを扱っている状態。そのデータに文脈や構造を与えることで情報となる。
・最後の味付けとしての品質：最後まで待ってテストを実行するのは災いのもと。全体として品質を高めるには、個々のコンポーネントの段階からテストを行い品質を高めておく必要がある。
・アラート疲れ：アラートシステムに多くのノイズを発生させてしまい、それらはすぐに無視されるようになり、アラートが発生しているのが正常だと見られてしまうこと。
・空の道具箱：細かな手作業が必要かつ、全体で設定もれ、反映漏れなどが発生してしまっている状態。適切なツールで自動化が必要。
・業務時間外のデプロイ：組織を守るため正当化されがちな作業となっている。
・せっかくのインシデントを無駄にする：問題が起きた時に新たな学びがある。安全運転だけでは、自分の理解の矛盾に気付けない場合がある。
・情報の溜め込み：ブレンドだけが知っている：意図的な行動を起こさない限り情報はキーパーソンに集中しがち。キーパーソンがいないとプロジェクトがストップしてしまう。
・命じられた文化：組織の文化が、メインロビーに飾られているくどい声明やプレートに記されているものの
、実際には具体的な形では存在しない場合に発生。文化は、育て、発展させ、言葉だけではなく行動で示す必要がある。
・多すぎる尺度：全体的な目標でなく、その目標の特定の部分に集中してしまう傾向がある。その特定の部
分が組織全体の目標より優先されてしまう。
主にシステム運用において、開発側と運用側がどう協業して問題を解決していくかの、一つの答えを提案してくれている。対象読者としてDevOpsなどを自ら推奨する権限のある立場でなく、一般のエンジニア視点で語られている点がポイント。DevOpsなどにおいてどう携わっていくか、アンチパターンを軸に知見を広げたい人に価値が出てくる著作だと感じた。
ーーーー
以下気になったメモ
１章：DevOpsを構成するもの
テスト不十分の構成のプログラムが自動タスクで本番環境にデプロイし問題発生
アクセス権を持っている人に連絡して、コマンドを読み上げてもらい対応する羽目に
＞変更承認プロセスの再検討
＞変更の内容を理解できない人が何人も承認したとしても変更の安全性は高まらない
DevOps:ソフトウェア開発の考え方を他の役割に適用するソフトウェア開発手法
職能の垣根を低くする。このアプローチは、セキュリティ(DevSecOps)、QA,データベース運用、ネットワーク、他などのグループにも拡張できる
まず人、次にプロセス、その次にツールなどについて考える
DevOpsの柱：CAMS
Culture:文化
Automation:自動化
Metorics:メトリクス:活動を定量化して得たデータを加工したもの
Sharing:共有
ーー
２章：パターナリスト症候群
チームをより効果的にする意図で作られたものが、むしろチームを停滞させてしまう
＞パターナリスト症候群
仕事の進め方、タイミングをゲートキーぱと呼ばれる権力者に委ねる＞生産性の低下を招く
責任がチームを跨いで重複している時＞アクセス権をつける＞しかし理不尽な結果が起きやすい
承認プロセス：うまく対処出来ないケースが発生するたびプロセスが重厚、確認事項が追加、承認者の追加
承認会議：変更のリスクを評価しようとするが、時間が経つにつれ判子を押すだけの委員会になる。変更の大部分はマイナスの影響がないため承認ハードルが低くなる＞変更承認は何の付加価値もない障壁となる。
DevOpsでは価値を付加するものは残しつつ、人為的な障壁を取り除くことに常に気を配る
人間の能力の浪費によるコストに焦点を当てる
永続的な価値をもたらす仕事を最大限に行うことに重点＞通常では５分で完了する作業を１週間かけて自動化もありうる
>自動化で他の人が待たされる作業を完了できる点に価値がある。
DevOpsのゴール
・チーム間のコラボレーションの強化
・不必要なゲートや作業の受け渡しの削減
・開発チームがシステムを所有するために必要なツールと権限の提供
・再現性のある予測可能なプロセスの構築
・アプリケーションの本番環境に対する責任の共有
CAMS
仕事のやり方に関する文化や考え方を変えて、無駄なゲートを取り除く
自動化で反復可能なプロセスを生み出す
文化の変化の責任の共有化でシステム状態を誰もが理解できるメトリクスが必要になる
共有により一部の人だけにDevOpsの理念を止めるのでなくチーム全体で成長可能に
ゲートキーパータスク：チーム間のやりとりに承認や依頼、権力の誇示がある活動のこと
ゲートキーパーはバターナリスト症候群の中心的存在＞信頼の欠如によってゲートキーぱが導入
いつもはシステムを誰も使用していない時間帯に、システムにパッチを当ててデプロイをしたが、実は臨時的にシステムを使用している人がいた。
＞問題となり変更管理プロセスが生まれる。
これで一つの問題は解決できそうだが、承認や日程の取り決めで、チームの負荷が増える、デプロイの回数も制限されるようになる。＞システム全体の変更を遅らせる事態に
問題の過剰反応がバターナリスト症候群を助長している
システム自体や、そのシステムによってどのように問題が発生しているのか検討する代わりに、チームはメンバーが下した個々の判断の良し悪しに着目＞非生産的
＞ワークフロー全体に余分な時間がかかるようになってしまう
自動化によるパターナリスト症候群の解消
承認プロセスなどを自動化＞現状では何の価値も生み出していないため
自動化に際して、エンジニアだけでなく、ゲートキーパーやプロセスに関わる人たちとチームで検討＞システムに対するあらゆる観点を考慮
・承認プロセス：許可するために必要なチェック項目
・ロギングプロセス：依頼、承認、実行、結果をどこまで記録するか
イシュートラッキングソフトウェアを活用＞チケットシステムを利用しログは一箇所に集約、自動コメント
・通知プロセス：自動ツールがどこで人々に通知するか＞プッシュ通知？
アプリから独立した既存の配信リストでメールアドレスを管理すれば、人の異動などにも対応:採用、退職、異動などの管理作業は避ける
・エラー処理：どの程度まで自動復旧するか
エラーの自動修正は避ける。情報を提示しユーザに判断を委ねる
自動スクリプトでも、それぞれの関心ごとを管理、保守可能なコードに分離する構成に
DevOpsのアプローチを繰り返し、継続的改善を行う
ーー
３章：盲目状態での運用
システムの本番環境で問題が発生しアラート通知が運用グループに届く。
アラートが何に注目すべきなのか情報が記載されていないため、ゼロから目ぼしい問題を調査。開発チームに問題をエスカレーション。開発チームは、本番環境の操作権限がない
ため、運用チームに指示を出しながら調査。
結果、SQLの処理の重いスロークエリが他のクエリをブロックしてWebサーバが処理待ちの状態であった。
問題：エスカレーションされた人たちは、トラブルシューティングに役立つシステムの状態を確認する権限を与えられていなかった。
チームメンバーは、システムメトリクスに関する情報を全て持っていたが、システムがなぜ誤動作したかを理解するには不十分だった。
そのシステム影響が、どう顧客に影響するかも理解が不十分
システムは、役に立つメトリクスは収集されておらず、パフォーマンスについて正しく答えられていない状態だった。
問題：開発と運用の役割
運用はシステムのメトリクスに異常がなければ、アプリケーションに問題があったとしても、実装の問題
逆を言えば、開発者は本番環境に移行した後の責任を負わない
ローカルで開発環境が再現できない問題はインフラに関わる問題
・・・としてきた
DevOps
運用チームもアプリケーションの実装内容を把握する
＞サポートするプロダクトを理解することで、必要で確認すべきメトリクスを深く理解できる。
機能やプロダクトをエンドユーザに迅速に提供することを継続的に推進することが目標。
＞チーム間の調整を少なくする
運用の可視化
メトリクス:システムリソースのある地点の測定値
スループット：一定期間内の処理量
エラー率：エラー数でなく、エラーの割合
レイテンシ:アクションが完了するまでの時間測定
ログ：イベントを記述したシステムが生成するメッセージ
の主要な情報源で可能になる
主要なメトリクスは開発側に委ねられている。
運用側は、カスタムメトリクスを開発する必要がある。
故障モード影響分析
・深刻度
・発生頻度
・検出可能性：エラー検出前に顧客がエラーに気づく可能性
これら３つのスコアに掛け合わせてリスク優先番号(RPN:risk priority number)を付与
大きいほど優先度が高い
予想外の障害だった物から障害を精度良く検知できるようになったら再評価して、数値を下げたりする。
障害があおきた後は必ずその障害を振り返るポストモーテムを行う
ログ集約システム：様なざま異なるシステムのログを集約し、一箇所で検索可能にする
構造化されたログ(jsonなど）はフィールドや値を取得するために複雑な正規表現が不要なのでログ取り込みが簡単になる
ログレベル
・DEBUG:デバッグ用
・INFO:システムの通常操作、アクション
・WARN:将来エラーになる可能性の状態、パフォーマンス低下など
・ERROR:全てのエラー状態
・FATAL:システムの致命的な問題
ログメッセージ
・何のアクションが実行されたか
・そのアクションの期待される結果は何か
・そのアクションの実際の結果は何か
・取るべき修復手順はなにか
・エラーによって引き起こされる潜在的な結果は何か
ログ集約システムのコスト
サービスを購入するのも手段
送信する情報の機密内容を場合によって取り除く必要あり
ーー
４章：情報ではなくデータ
データに文脈や構造を与える＞情報となる
ダッシュボードの対象者を特定することで、どのメトリクスを表示するか、強調するか、粒度などを決めることができる
ウィジェット・ダッシュボードで情報の可視化
・折れ線グラフ
・棒グラフ
ウィジェットに文脈を与える：データの良し悪しを示す分脈を与える
・色による分類
・閾値線
・時間比較
重要な項目が最初に目に入るようにダッシュボードを構成
ーー
５章：最後の味付けとしての品質
アンチパターン：最後の味付けとしての品質
全体として品質を高めるには、個々のコンポーネントの段階からテストを行い品質を高めておく必要がある。最後まで待ってテストを実行するのは災いのもと
テストケースの数だけを指標にして、肝心な部位のテストが不十分の可能性
テストピラミッド
（上）
・エンドツーエンドテスト:時間がかかるが、ユーザ視点でアプリをテスト
多くの機能を試す＞テスト時間は長くなる、範囲も大きい
・結合テスト:複数のユニットをまとめてテスト
モックだった物を実際のコンポーネントにする、DB接続など
・ユニットテスト:ピラミッドの基礎となるテスト。最も数が多く高速
他のAPI呼び出し処理をモック化してテスト
（下）
ピラミッドの上に行くほど、テスト速度が低下し、テストに影響を与える外部要因も増える
コンストラクトテスト：サービスに対して実行される別個のテストセット。エンドポイントの入出力が期待通りの動作をしていることを確認するもの
テストスイート：テストスイートに対する信頼性が低下したら早急に対処する
＞テストスイートは失敗が発生したらすぐに失敗するべき
＞不安定なテストを許容しない＞改善対象とする
虚栄のメトリクス回避
・登録ユーザ数：アクティブユーザとは違う
・テストカバレッジ：必ずしも品質や何がテストされているか示す物ではない
DevSecOps
開発の最後だけでセキュリティチェックが入った状態になっていないか
セキュリティの観点から設計がされているか、プロセスの早い段階で設計の決定に関与できるようにする。
ーー
６章：アラート疲れ
問題：アラートシステムに多くのノイズを発生させてしまい、それらはすぐに無視される
ようになり、アラートが発生しているのが正常だと見られてしまうこと＞アラート疲れ
本来の重要なアラートに鈍感になってしまう
SLO：サービスレベル目標
・確認までの時間
・開始までの時間
・解決までの時間
アラート基準
異常だと思われる可能性のあるシナリオ全てに対してアラートを送信する罠
閾値での管理
正確な閾値がわからない、パフォーマンスがわからない場合は、アラートの作成は一旦延
期してデータ収集する
良いアラート
・行動可能である
・タイムリーである
・適切に優先順位がつけられている
異常検知：
閾値ベースでなく、データのパターンの中から異常値を特定するプラクティス
異常検知が機能するまで、十分な履歴が必要
オンコールローテーション
最小構成：４人
それ未満になるとプライマリオンコール、セカンダリオンコールを連続することになってしまう
構成人数が多すぎても回ってくる回数が少なくて経験が習熟しない
オンコール担当者を増やしても必要なツールやアクセス権がないのは最適でない
＞自動化を実践するこのとの重要性が増す
>６人〜８人規模が妥当＞必要に応じてサービスを分割して担当配置してみる
オンコールへの保証
・金銭的保証
・休暇
オンコールの幸福度を追跡する
・特定の週、日に集中していないか＞誰かに集中してないか
・受けた人のアラートの重要度を追跡する
・通知方法：呼び出し全てはオンコールエンジニアのストレス要因になる
・どの時間帯にアラートを受けているか
ーー
７章：空の道具箱
細かな手作業が必要かつ、全体で設定もれ、反映漏れなどが発生してしまっている状態。
適切なツールが必要＞自動化
厳密な手順があっても、手動では失敗の危険がある。
手作業に費やす時間が多いほど、プロダクトに付加価値を与える時間は少なくなる。
自動化による改善
・待ち時間を削減
・実行時間を削減
・実行頻度を必要に応じて高い頻度にする
・実行開始時間のばらつきの解消、再現性を高メル
>これまでアクセス権が必要だったり、知識伝達が必要だったタスクを、より多くのスタッフが実行できるようになる
自動化しない悪い理由
・自動化の労力を大きいと見積もっている
手動で毎回１時間で済むなら、自動化に８時間かかるなら、手動で済ませたい。
・GUIベースでしかファイルアップデートできない環境で、コマンドラインは公開されていない。これを自動化するには、マウスクリックやドラッグをシミュレートしたアプリが
必要＞コマンドラインよりはるかにデリケートで不安定＞問題が発生しやすい
・自動化できないツールばかり使うと、自動化のための必要スキルが退化する。
手動と児童の間の妥協点
スコアカードを使った採点で決める
ツールチェイン：例えるならある価値を実現するためのアプリ、スクリプト、プログラム言語のこと
ツールを評価する場合、自動化が必要な場合は、そのツールチェインで自動化が可能でなければならない。
自動化のアプローチ
・タスクにおける安全性：タスクを不正確に実行されても危険な結果をもたらさない
・安全のための設計：危険な操作の実行抑止（確認処理）と実行監査証
ーー
８章：業務時間外のデプロイ
遅いリリースの悪影響
・リリースの詰め込み：リリースの規模が大きくなりリスクが高くなる
・リリース頻度が低くなると、次のリリースに合わせるため大急ぎの機能実装が出てくる
・リリースのリスクで、失敗の影響が大きくなると承認や変更管理の層を増やしてプロセスが厳しくなる
テプロイレイヤ
・機能デプロイ：アプリケーション全体で新機能を有効にするプロセス
・フリートデプロイ：複数サーバにアーティファクトをデプロイ
・アーティファクトデプロイ：１台のサーバに新しいコードをインストールするプロセス
・データベースデプロイ：新しいコードのデプロイの一環としてデータベースの変更を伴
う
正確な本番前環境
・残念ながらステージング環境はコスト削減対象になりうる
フォーカスすべきは、アーキテクチャ的に同じ環境を実現すること
Docker,Kubernetesの活用
合成トランザクション：ユーザが通常行うであろう活動をシミュレートするために作成されたスクリプトやツールのこと
フィードバックループ：システムを守ろうとする行為そのものが、その原因となる状態につながっていること。＞デプロイを遅くすることは、変更の数が増えてデプロイを危険なものにする
ブルーグリーンデプロイ：既存のサーバにコードをデプロイするのでなく、新しいコードを実行する新しいサーバを作成する手法＞クラウドでよく見られる
失敗したら、旧構成のインスタンスに戻せば良い>ロールバックが簡単
ロードバランサのさし先を切り替える必要あり。段階的に行うこともできる。
注意点：
新旧でデータスキーマの互換性がないといけない
バックグラウンド処理の重複に注意
ローカルサーバに情報を保存するアーキテクチャはNG
デプロイアーティファクトのロールバック
あるサーバX群にパッケージをインストールしロールバックが生じる。結果としてサーバY群にはインストールされない。これが数十回ほどのデプロイが起こると、X群とY群は全く
同一でなくなる。＞OSのパッケージ管理システムを活用すべき
データストレアレベルのロールバック
データベース・カラムの型を変更して機能をリリースしたのち、ロールバックが必要になった場合
・問題を修正して再度デプロイ
・テーブルの型を戻し、値を戻してからコードをロールバック
どちらも魅力的な選択肢ではない
・列の型変更でなく、列を追記していく方法にする
・ある列の更新処理で、新しい列にデータを書き込むようにする
・古いカラムが不要になったら削除
＞リリースステップが増えるが、古いバージョンとの互換性を保てる
キーバリューストア：
キーの配列を格納するデータベース。各キーは対応する値を持つ
HTTPインタフェースを介してアクセス可能
設定情報の保存に最適なツール
各種サーバの設定情報を起動時に取得するようにする。
機密情報を平文で置くのはNG
キーバリュストアーがアプリプロセスのクリティカルパスになるので注意
デプロイパイプラインの自動化
＞サーバの停止、起動、スキーマの変呼応、ソフトウェアのデプロイ、これらを全ての所定ノードで実行するまでを自動化
ーー
９章：せっかくのインシデントを無駄にする
問題が起きた時に新たな学びがある。安全運転だけでは、自分の理解の矛盾に気付けない場合がある。
ポストモーテム：チームがインシデントに至るまでの出来事を評価するプロセス
責任のなる試合から脱却するためには、システム、プロセス、ドキュメント、システムの
理解の全てが、どのように指定インシデントに繋がったか考えなければならない。
ポストモーテムが懲罰のための取り組みになってしまわないように注意
>学習と成長の機会を失う
>人を批判しない、行動や振る舞いに焦点を当てる
>最終目標は、インシデントに関与した全ての要素を理解すること
イベントのタイムライン
・どのようなアクション、イベントか
・誰が行ったか：役割、地位などが恒久的
・行われた時刻
イベントに文脈を加える
・なぜ正しい行動だと感じたか
・システムで何が起こっているかのようについて、なぜそのように解釈したか
・他の行動を検討したか、検討して排除した場合はその理由
・他の人がアクションを取る場合、自分の持っている知識をその人はどのように得るか
正しい行動であっても、その正しい行動をとるに至った経緯を理解するのは重要
その中でシステムの閾値、通知内容、通知方法、ログなどでの不備、過不足を洗い出せる
今後実行すべきアクションアイテムも決める
誰が、いつまでに、何をするか：で定義する。
短期目標：合理的な時間内に実行可能なタスクで優先度高い
長期目標：多大な労力を要する項目。上層部による優先順位づけが必要
・実行する必要のある作業な詳細
・チームが考える、その作業時間見積り
・作業優先順位を決める決定権のある人
ポストモーテムのドキュメント化
同じ問題が起きた時の歴史的記録
対象者ごとに節を設けわかりやすく
インシデント詳細
・発生日時
・解決日時
・インシデントが継続していた期間
・影響受けたシステム
ポストモーテムの共有
エンジニアリング組織全体で共有
ーー
１０章：情報の溜め込み：ブレンドだけが知っている
意図的な行動を起こさない限り情報はキーパーソンに集中しがち
キーパーソンがいないとプロジェクトがストップ＞アンチパターン・ブレンドだけが知っている
共有知識の現実は、wikiに載せるだけでは不十分
情報の溜め込み
・意図的に溜め込んでいる人
・意識せずに溜め込んでいる人
組織の中で危険なのは、古いままの詳細なドキュメント
ナレッジストアの構築
ドキュメントレポジトリ
・共通の辞書を使用：
・１つのマスタドキュメントにリンクされた階層構造のドキュメント
プロセスや部門やチームの境界を肥えている場合、相互にドキュメントをリンク
・部門でなく、トピックを中心に文章を構成
部門中心だと情報が分散しがち
学習の習慣づけ
・ランチ＆ラーン：昼休みに大勢の徴収に向けて行うプレゼン
・ライトニングトーク：５〜１０分程度のプレゼン
・ブログでの発表：聴衆の前での発表が苦手の人向け
チャットツールで情報共有
ログを検索可能にすること：日付＋事象などでユニークにする
ーー
１１章：命じられた文化
組織の文化が、メインロビーに飾られているくどい声明やプレートに記されているものの、実際には具体的な形では存在しない場合に発生
文化は、育て、発展させ、言葉だけではなく行動で示す必要がある
文化とは
価値観、習慣、信念
文化チーフ：組織の文化的価値観を体現する社員。影響力がある人物
対立の火種を抑止する
・確固たる事実と、その事実から導き出された視点や意見を明確に分ける
・議論の余地のある表現を使う
・自分の行動の最終目標を明確にする
ーー
１２章：多すぎる尺度
全体的な目標でなく、その目標の特定の部分に集中してしまう傾向がある。その特定の部分が組織全体の目標より優先されてしまうアンチパターン。
目標設定と優先度順位づけのプロセスが重要
目標の階層
組織全体の目標＞部門の目標＞チームの目標
優先度、緊急度、重要度
>アイゼンハワーの意思決定マトリクス
チームの仕事を整理
作業を細分化＞イテレーションの作成
予定外作業のコントロール
・入ってくる仕事を評価
・その仕事がどこから来たか記録
・本当に緊急かどうか判断。緊急なら実行、そうでなければ後回し
・集中している作業が終わったら、後回しにした仕事をさらに詳しく評価し作業日を決める
以上。
へポスト