巻頭言：SREのアンチパターンを改めて探ってみよう
はじめに
こんにちは。しょっさん（@syossan27）です。
今回は、SREのアンチパターンについて軽くですが探求してみます。
アンチパターンについて
SREのアンチパターンというと、「SREの探求」における23章にパターンの一覧と、その解決法が記載されています。
まずはこれを改めて紐解いてみましょう。
SREの探求でのアンチパターン
■ サイトリライアビリティ オペレーション
業務内容や権限の見直しを行わずに、運用 → SREという看板を掛け替える
■ 画面を見つめる人間
問題の発見を、人間の目による監視に依存し、自動化されたアラートや監視システムを導入しない
■ 群衆によるインシデント対応
インシデント対応する人員を最適な人数で行うことを考えず、全員で取り組む
■ 根本原因=ヒューマンエラー
根本の原因がヒューマンエラーという結論に至る
『善意の人間でも「壊す」ことができるのなら、それはすでに壊れていたのです』
■ ページャーの引き渡し
インシデント対応を、システムの作成を行っていないチームや個人に割り当てる
■ マジックスモークを消すのは私だ!
インシデントの対応を"英雄的行為"として評価する
マジックスモークとは、工学系の俗語で「部品に込められた"魔法の煙"が作用することで、機械が動作する。魔法の煙が部品から出ることで（つまりは故障）、機械が動作しなくなる」といった意味
■ アラートリライアビリティエンジニアリング
アラート過多となるように通知設計してしまう
■ ペットを散歩させてくれるドッグウォーカーを雇う
ミュータブルなインフラストラクチャのスケールのために、PuppetやChefなどの設定管理ツールを利用する
■ スピードバンプエンジニアリング
明確な価値や、フィードバックが無いのにプロダクションリリースまでを遅くするような施策を取り入れる
スピードバンプとは、自動車の速度を落とさせるために道路上に設置された隆起部分のこと
■ 設計の難所
SREに関するチームの人員が、プロダクションチームに設計・運用のベストプラクティスをコンサルティングし、標準化・自動化などを整備しない
■ 棒が多すぎてニンジンが不足
フレームワークや、プラクティスの導入をプロダクションチームに対し、一方的に押し付ける
SRE はプッシュ型の機能ではなく、プル型の機能です
■ プロダクションの延期
プロダクションリリースに慎重になりすぎて、リリースが遅れる
■ リカバリ時間ではなく障害回避の最適化(MTTF > MTTR)
障害を避けることに注力をしすぎて、障害の検出・修復の迅速化を疎かにする
■ 依存性地獄
システムの相互依存が把握困難なほどに複雑化し、依存の追加を検出するなどの対策を取らない
■ 小回りの利かないガバナンス
リーン、アジャイル原則の導入に消極的な組織では、SREを実践することは非常に難しい
■ 不適切な「おやおや」の SLO
SLOがユーザー・ビジネスからのインプットによる変更がなく、放置状態にあるSLO
■ ファイアウォール越しにAPIを投げ渡す
SREに関するチームとプロダクションチームがサイロ化し、サポートチケットを切って対応するなど"ファイアウォール"が存在する
■ 運用チームの修復
SREを"運用の修復"をする役割として位置づけ、組織全体の改善に取り組まない
SREの探求では、このような18種のアンチパターンが挙げられています。現場で実際に体験するようなアンチパターンも存在すると思いますが、このアンチパターンが全てではないはずです。
23章も「私がこれまで調べて回ったのはそのほんの一部でしかないことから、このリストは今後も成長し続け、業界の変化に応じて変化し続けるものと想定しなければなりません」と述べています。
アンチパターンが他にも存在することは分かりましたが、どのようなものが他に発見されているのでしょうか？
それを少しながらですが、探求していきましょう。
本章内で、“Twitterで私のアカウント@BlakeBissetに、#SREantipatternsを記載してツイートしてください。“という呼びかけがありましたが、特にツイートがありませんでした。かなしい。
Top SRE Anti-Patterns and How AWS Can Help Overcome Them
こちらの記事は、SREのアンチパターンとそれを乗り越えるためのAWSソリューションについて紹介されている記事です。
この中で様々なアンチパターンが挙げられていますが、特徴的なものをピックアップしましょう。
Incorrect Ticketing（チケットの不正発行）
「アラートリライアビリティエンジニアリング」に関連するアンチパターンですが、自動的に解決するような問題（例えば、オートスケールで解決するようなトラフィック問題など）がチケットとして発行され、SREチームの注意が削がれてしまうといったパターンです。
AWS Systems Managerを利用した解決策を提示していますが、要はそういったアラートを無為に発行しないようにすることが重要です。一例として、オートスケールするシステムなのに、CPU/メモリの使用率が閾値を超えたらアラートを発行するといった設定は避けるべきです。
Over-reliance on War Rooms（障害対応本部への過度な依存）
インシデントレスポンスの文脈で、War Roomsは言葉として浸透してきていますが、この場合のWar Roomsはインシデント時に"物理的に"集まって対応を進めることを指しています。
このような物理的な集まりのみでインシデントを解決していくことは、コラボレーションが発生せず、あまりよろしくありません。
必ず、インシデントレスポンスはバーチャルな場で行いましょう。日本ではTopotal社が提供している「Waroom」というツールがありますが、こういったツールを使い、バーチャルでのインシデントレスポンスを迅速に行うのも一つですね。
Chasing Nines（9の追求）
SREの世界では、可用性を9で表現することが一般的ですが、この記事では「9の追求」をアンチパターンとして挙げています。
99.9999….と9を増やす行為には、非常にコストがかかります。ひたすらに追求を目指すのではなく、ビジネスチームなどとどこまでの可用性が求められるのかを明確にし、そのレベルでの対応を行うことが重要です。
Overcoming SRE Anti-Pattern Roadblocks: Rebranding the Operations Team | Conf42
こちらの記事は、Conf42というオンラインテックイベントのSREトラックで行われたセッションの内容をまとめたものです。
Googleのアプローチを鵜呑みにしない
SRE本はGoogleのアプローチを元に書かれていますが、Googleが提示したプラクティスをそのまま適用することが最適とは限りません。 ましてや、すべてのプラクティスを適用することは良い結果をもたらさないこともあります。
常に、「なぜ自社でSREが必要なのか？」を問い続けて、活動を続ける必要があります。
このことについては、私が好きなNiall Murphy氏による「SRE in the Real World」という記事内でも触れられており、Googleと他社とで状況が大きく異なることを認識し、SREを推し進めることが大事です。
アンチパターンからSREを理解する | Sreak
最後に、株式会社スリーシェイクの運営サービス、Sreakさんのブログによる記事から紹介します。
改善フェーズの欠落
SREの実践において、とかく施策の実施が多く走ることになります。SLI/SLO, エラーバジェット, Runbook等のドキュメンテーション, Four keysなどの生産性指標などなど…
それらの施策を実施することは重要ですが、それらを実施するための改善フェーズが意図的でないにしろ欠落してしまうことがあります。必ず、実施とセットで改善フェーズを計画し、定期的に振り返りを行うことが重要です。
まとめ
今回挙げたように、SREの探求以外で言及されているアンチパターンには様々なものがあります。現場の状況や、組織の文化によってアンチパターンは異なるため、無尽蔵にあるとも言えるかもしれません。
ただ、類似する状況に困っている人がいるかもしれないということを考えると、アンチパターンを共有し、その解決策を考えることは非常に重要です。