頑張らないように頑張る。

努力と怠惰の狭間

「システム運用アンチパターン」を読んだのでまとめた。

オライリー社から出版されている「システム運用アンチパターン―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション―」を読んだのでまとめた。

www.oreilly.co.jp



📖前提

1章ではアンチパターンについては語られず、DevOpsについて語られている。

1章:DepOpsを構成するもの

DevOpsを支える4つの柱「CAMS」

  • Culture(文化)
  • Automation(自動化)
  • Metrics(メトリクス)
  • Sharing(共有)

DevOpsでは、CAMSによって、以下のゴールを目指す。

  • チーム間コラボレーションの強化
  • 不必要なゲートや作業受渡しの削減
  • 開発チームがシステムを所有するために必要なツールと権限の提供
  • 再現性のある予測可能なプロセスの構築
  • アプリケーションの本番環境に対する責任の共有

DevOpsムーブメントの重要な点は、以下2つ。

  • 文化的な問題に正面から取組んでいる事
  • 人間の労力の浪費によるコストに焦点を当てている事



📖アンチパターン紹介

アンチパターンの説明は2章以降で語られる。
「章タイトル=アンチパターン名」なので、それぞれについて見ていく。


2章:パターナリスト症候群

信頼の欠如によりパターナリスト症候群が発症し、過剰なまでのゲートキーパータスクが生まれる。

ゲートキーパータスクは、以下のような問題を発生させる。

  • システム全体の変更を遅らせる
  • 余分なコミュニケーションが増える
  • ヒューマンエラーでデプロイができなくなる など

以下の手順で、パターナリスト症候群を解消する。

  1. チームを編成
  2. プロセスを自動化するメリットを議論
  3. アプローチの概要を作る
    • 承認プロセス
    • ロギングプロセス
    • 通知プロセス
    • エラー処理
  4. 上層部に伝える
  5. 実行する

※重要なのは、何の価値も生み出していないプロセスを自動化する事(全部が全部自動化したいわけではない。必要な手作業も存在する。)


3章:盲目状態での運用

開発者は、
自分のコードが本番環境でどう動作しているのか理解する必要がある。
(「開発環境で動いてるんだから、アプリには問題ない」と責任転嫁しない)

運用者は、
プロダクトを理解する必要がある。
(「機能や挙動はアプリの範疇であり、インフラには関係ない」と責任転嫁しない)

お互いにお互いのせいにせず、見える化するために「メトリクス」と「ログ」を整える。

メトリクスは、以下の通り。

  • スループット:どのくらいの頻度で処理してる?
  • エラー率  :どのくらいの頻度で失敗してる?
  • レイテンシ :完了するまでどれくらいかかる?

ログは、以下の通り。

  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL


4章:情報ではなくデータ

「データ」は、整理されていない生の事実。
「情報」 は、データに構造や文脈を与えたもの。

「データ」を「情報」に昇華させるため、以下を行う。

  1. 構造化するためにウィジェットを作る(折れ線、棒、ゲージなど)
  2. 文脈を与える(色付け、閾値、時間比較など)
  3. 優先度をつけて配置する(緊急度、重要度など)
  4. 命名する(対象のウィジェット=情報を見つけやすいように)


5章:最後の味付けとしての品質

継続的デプロイ・継続的デリバリをするため、以下を行う。

  1. デプロイパイプラインを作る
  2. 自動テストを行う

「DevOps」ではなく「DevSecOps」の観点だと、デプロイパイプライン上で以下も行う。

  • セキュリティスキャン
  • セキュリティテスト

テストインフラは、運用チームが管理・所有する。
(本番環境で何が動いているかを把握すべきは運用チーム。
 そのためのテストコードやテストスイートを提供しているのが開発チーム。)


6章:アラート疲れ

頻繁に多くのアラートに晒される事で、アラートに鈍感になっていく症状。
(システム的にも、メンタル的にも、従業員満足度的にも、危険な症状。)

これを解消するためには、オンコールローテーションを導入する。

  • 4~8人のチームで、1週間ごとに交代する
  • オンコールを担当するスタッフには、担当する週はオンコールサポートプロジェクトに専念させる(他業務は他スタッフに任せる)
  • スタッフとして、プライマリ・セカンダリ・マネージャを配置する
  • スタッフには補償を設ける(金銭?休暇?在宅勤務?)
  • SLOを定義する(確認までの時間、開始までの時間、解決までの時間)
  • アラート発生時は、"解決"ではなく"トリアージ"にフォーカスするのも大切
  • いつ・誰が・どんなアラートを受けて対応しているかを追跡する

なお、「良いアラート」とは、以下の通り。

  • 行動可能である
  • イムリーである
  • 適切に優先順位付けされている


7章:空の道具箱

「自動化しましょう」という話を長ったらしく書いてるだけなので、ここでの説明は割愛。

図7-5は重要なので、これについては書籍で確認してください。 (完全な自動化ではなく、ユーザの確認や入力が必要なケースも存在するため)


8章:業務時間外のデプロイ

リリースプロセスが遅いと、以下のような悪影響を及ぼす。

  • リリースの詰め込み
  • 大急ぎの機能
  • 重厚な変更管理プロセス など

デプロイは日常的に行う必要があるが、以下のような問題も抱えている。

  • 本番環境とST環境の構成を同じにできない
  • 並列実効性や想定外のユーザ実行など不確定要素も多い など

デプロイが遅れたり失敗したりすると、フィードバックループの悪循環が起きる。(図8-2)

デプロイを頻繁に行う事で恐怖心を払拭するため、以下を行う。

デプロイは、以下のレイヤで考える。

  • 機能デプロイ
    • 機能フラグを設けるとよい
  • フリートデプロイ
    • ブルーグリーンデプロイやローリングデプロイを行う
  • アーティファクトデプロイ
    • OSのパッケージ管理システムを使う
  • データベースデプロイ
    • ALTERやCRUDやバージョニングなどのルール決めをしておく


9章:せっかくのインシデントを無駄にする

懲罰や非難の文化があると、インシデントが発生した時に、責任のなすりつけ合いが発生し、透明性が欠如していく。

問題は「個人」ではなく「システム」にあるので、システムに焦点を当てた上で、以下を行う。

インシデント発生時は、

  1. 24時間ルール(*1)を厳守した上で、
  2. ポストモーテム(*2)を実施し、
  3. 文書作成(*3)も行う。

*1: 記憶が薄れないうちに。感情やエネルギーが冷めないうちに。
*2: 「アフターアクションレポート」「インシデントレポート」「レトロスペクティブ」とも言う。
*3: 発生事象/直接原因/一時処置/根本原因/影響範囲/恒久処置をまとめる。


10章:情報のため込み:ブレントだけが知っている

情報のため込みは、ゲートキーパーの行動が適切か評価されていない事で生じる。

  • ため込みが、意図的でない場合は、本人に自覚させる必要がある
  • ため込みが、意図的な場合は、吐き出させる必要がある
  • ため込みが、文書化の軽視により発生している場合は、吐き出させる必要がある
  • ため込みが、不適切なアクセス制限によって発生している場合は、権限を見直す必要がある

ナレッジの共有には、以下を行う。

  • ナレッジストアの構築
  • チャットツールの導入 など

ナレッジを根付かせるには、以下を行う。

  • ランチ&ラーン
  • ライトニングトーク
  • 外部イベント参加 など


11章:命じられた文化

ピーター・ドラッガー『企業文化は戦略に勝る』

文化には、以下3つの要素がある。

  • 文化的価値観
  • 文化的習慣
  • 信念

文化を根付かせるには、以下を行う。

  • 上記3要素と体現してくれる「文化チーフ」を探す
  • 「社会的習慣」「プロセス的習慣」からアプローチする


12章:多すぎる尺度

アイゼンハワーの意思決定マトリクスに従い、「緊急度×重要度」を定めて、タスク管理する。



😶最後に

個人的な感想だが、章立てが分かりづらかった。

どこがアンチパターンで、どこが事例紹介で、どこが解法なのか、、、というのが章立てとして体系的にまとまっておらず、頭の中で整理しながら読まないといけなかったので、辞書的に読み直すのは困難そうだなと感じた。


あと、本書のターゲットユーザが分からなかった。

アンチパターンを求めている人には11個しかないので少なく感じる。初学者にはボリュームが多いし業務にも寄り過ぎている。感覚的には業界歴2,3年の人が読む感じ・・・??


という余談。

https://www.oreilly.co.jp/books/images/picture_large978-4-87311-984-7.jpeg