パターナリスト症候群

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

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

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

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

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

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

• 参考文献
  • システム運用アンチパターン

盲目状態での運用

開発者は、自分のコードが本番環境でどう動作しているのか理解する必要がある。（「開発環境で動いてるんだから、アプリには問題ない」と責任転嫁しない）
運用者は、プロダクトを理解する必要がある。（「機能や挙動はアプリの範疇であり、インフラには関係ない」と責任転嫁しない）

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

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

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

ログは、以下の通り。

• DEBUG

• INFO

• WARN

• ERROR

• FATAL

• 参考文献

  • システム運用アンチパターン

情報ではなくデータ

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

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

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

• 参考文献
  • システム運用アンチパターン

最後の味付けとしての品質

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

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

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

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

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

• 参考文献
  • システム運用アンチパターン

アラート疲れ

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

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

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

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

• 行動可能である

• タイムリーである

• 適切に優先順位付けされている

• 参考文献

  • システム運用アンチパターン

空の道具箱

「自動化しましょう」という話。
以下の参考文献のうち、図7-5が重要なので、是非書籍で確認してください。（完全な自動化ではなく、ユーザの確認や入力が必要なケースも存在するため）

• 参考文献
  • システム運用アンチパターン

業務時間外のデプロイ

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

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

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

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

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

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

• デプロイアーティファクトの作成
• デプロイパイプラインの自動化

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

• 機能デプロイ

  • 機能フラグを設けるとよい

• フリートデプロイ

  • ブルーグリーンデプロイやローリングデプロイを行う

• アーティファクトデプロイ

  • OSのパッケージ管理システムを使う

• データベースデプロイ

  • ALTERやCRUDやバージョニングなどのルール決めをしておく

• 参考文献

  • システム運用アンチパターン

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

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

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

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

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

• 参考文献
  • システム運用アンチパターン

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

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

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

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

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

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

• ランチ＆ラーン

• ライトニングトーク

• 外部イベント参加　など

• 参考文献

  • システム運用アンチパターン

命じられた文化

ピーター・ドラッガー『企業文化は戦略に勝る』
文化には、以下３つの要素がある。

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

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

• 上記３要素と体現してくれる「文化チーフ」を探す

• 「社会的習慣」「プロセス的習慣」からアプローチする

• 参考文献

  • システム運用アンチパターン

多すぎる尺度

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

• 参考文献
  • システム運用アンチパターン