最近 SRE について少しずつ学習しています。
その理由は、少人数で大企業のクリティカルなシステムを設計・構築・運用をし続けるという環境にあるからです。
クラウドサービスの AWS をプラットフォームとして数百台のインスタンスを少人数で管理しているためやり方を変えていかなければいけません。
昔ながらのやり方を捨てて「新しい文化を作る」くらいの勢いが必要です。
そんな環境の中でどうすればいいのだろうかといろいろ調べていくうちに「SRE（Site Reliability Engineering）」という考え方に行きつきました。
以前から「SRE」という用語そのものは知っていましたが、正直言って意味は分かりませんでしたし詳しく調べたりもしませんでした。
しかし初めて SRE について学習をしていく中で、SRE という考え方は現在の自分が置かれている環境にとってすごく有用だと思うようになりました。
ただ単に学習をして終わりではなく、後から振り返っても過去に学習した内容を思い出せるように備忘録として学習メモを残そうと思います。
SREの探求を読む
オライリージャパンの「SREの探求」という分厚い書籍を読みながら学習をしていきます。
今手元に書籍がありますが、全部で610ページあります。
しかも文字が小さくてぎっしりと詰まっています。
分厚い書籍を手に取るとわくわくしますが、その一方「これ、絶対に読めないやつだ」と絶望感も感じます（笑）
ということで体裁は気にせずに順番も何も考えずにひたすら学習メモを記載していきます。
「人は危ないと感じると情報を隠そうとする意識が働くものですが、SREが機能するためにはオープンで協力的な雰囲気が必要です。例えばチームによっては、サービス障害の原因と作った責任があるものに対して、適切なインシデント対応とポストモーテムでフォローアップする場合には、懲罰ではなく報酬を与えるところがあります。」
これは理解できます。
私も自分が原因で障害を発生させたときに、まず最初に否定から入ってしまいます（笑）
例えば、ネットワーク環境の設定変更をしているときに、上司や運用メンバーや開発メンバーがやって来て、
「現在、サービス障害が発生しているけどインフラで何か作業している」
「いえ、何もしていません」
いやいや、ちょうど今ネットワーク環境の設定変更をしていますが、なぜか勝手に口が動いて「いえ、何もしていません」と言ってしまう。
これはあるあるですよね（笑）
で、その直後に神妙な顔をして「いや、ちょっと待ってください。ちょうど今ネットワーク環境の設定変更をしていましたね。ひょっとしたら可能性があるかもしれないのでちょっと調べてみます」と答える。もちろん、心の中では100％自分が原因だと気が付いているわけです（笑）
で、キーボードをある程度カタカタ言わせた後に「あ、ひょっとしたら今回の作業が原因の可能性があります。念のため元に戻してみましょうか」と提案して元に戻して復旧させる。
特殊な人間ならまだしも普通の人間はこんなアプローチになります。
つまり人は危ないと感じるととりあえず否定して何か隠そうとしますね（笑）
コメント