SREに取り組むために
SREの責務や必要なスキルについて理解を深めたところで、SREをどこからはじめればよいかの本題に入ります。
プログラマブルに運用を行う
SREとして仕事をしていくにあたり、一番はじめに変えるべきことは、プログラマブルに運用をしていく意思統一です。現状の運用は、この時点では考慮しなくても構いません。
自社での運用業務の現状を考慮すると、もしかしたら気が遠くなるかもしれませんが、まずは、「プログラマブルに運用を行う」ことを決意し、チームで意思統一することが必要です。
なぜなら、SREは「ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるもの」なので、プログラマブルに問題解決を行うことが本質的な部分だからです。
例えば、前述した「変更管理」にInfrastructure as Codeの考え方を適用するのは分かりやすい例です。他にも、コーディングすることで、特定の運用業務を効率化・自動化していくこともプログラマブルに運用を行うことの分かりやすい例でしょう。プログラマブルに運用を行うべき範囲は各社異なっていると思います。ですので、まずは、現状を俯瞰してみましょう。
運用業務の土台を整える
さて、コードを書いて運用業務を効率化・自動化していくには、時間が必要です。そのため、運用業務の現状がボロボロになっている状態であれば、SREを実践していくにあたり、まずは土台整備から行うべきでしょう。
運用業務の土台が整備できていない状態とはどういう状態でしょうか。目安として、以下の状態であれば土台整備する必要があると筆者は考えます。
- サービス稼働に必要不可欠な運用業務が1人しか実施できない状態かつ、その業務のドキュメントが整備されていない
- サービス稼働に問題が起こったことを検知できず、かつ問題の原因究明が行われない(または原因究明を行う時間がない、もしくは原因究明を行う技術力が自社で不足している)
- 上記のような状態にもかかわらず、サービス運用の改善に対する問題意識が薄い
このような状態であれば、プログラマブルに運用を行うための業務に集中する時間の確保が難しい状態でしょう。では、どうすればこのような状態を脱することができるでしょうか。
バス因子に対処する
まず第一にやらなければならないことは、バス因子に対処することです。バス因子とは、書籍『エラスティックリーダーシップ』に登場する表現で、バスに轢かれてしまい、いなくなってしまったらプロジェクトに大きな影響を与えてしまう人物のことです。つまり、プロジェクトにとって必要不可欠な人のことです。
では、バス因子に対処するとはどういう意味でしょうか。簡潔に書くと「その人に依存しなければならない状況を可能な限り減らすこと」です。
運用業務であれば、スキル移管をすることで、複数人が同様の運用業務を実施できるようにすることが必要です。また、ドキュメントを整備することで、スキル移管するだけでなく、チームで運用業務を共有することも重要です。
そうすれば、チームで運用を回す土台が整備できるでしょう。また、1人で運用していたとしても、自分が突然いなくなってしまったとしてもプロジェクトは存続できます。
PDCAではなくOODA
次に、サービス稼働に問題があった際に検知できる環境を整備する必要があります。これは端的に書くと、モニタリングを整備することです。モニタリング結果から分かったことをもとに、実際に改善を行っていくことで、サービスの信頼性を向上させます。
筆者は「SREは、PDCAではなくOODAを回すことが重要」だと考えています。
- OODAループ(Wikipedia)
OODAは、アメリカ空軍のジョン・ボイド大佐によって提唱された理論で、指揮官のあるべき意思決定プロセスを分かりやすく理論化したものです。OODAとは、観察・監視(Observe)、情勢への適応(Orient)、意思決定(Decide)、行動(Act)の略です。
運用業務に関わっている読者の方は、身をもって体感されていると思いますが、サービス運用業務では、不確実性が高い状況に度々直面します。そのため、どこからどうやって手を付けていくかをPlanするよりも、まずObserveするべきです。
OODAを回す準備が整えば、SREとして仕事をしていく基盤が整ったと言えるでしょう。
サービス信頼性階層
本記事の最後に、信頼性という抽象的な概念を、どのような要素として理解すればよいかについて補足します。
以下は、書籍『Site Reliability Engineering』に登場する「Service Reliability Hierarchy(サービス信頼性階層)」の図です。
モニタリングが重要である点は前述しましたが、その次に整備すべきは、Incident Response(インシデント対応)です。ここで言う「インシデント」とは、セキュリティインシデントに限定した話ではなく、障害対応全般だとご理解ください。
「そりゃ、障害が起こったら対処くらいしているよ」と思われた方もいらっしゃるかもしれません。しかし、ここで言うIncident Response は、単に問題に対応すればよいというものではありません。「インシデント管理プロセスが、チームで共通化された効率的な対応フローになっているかどうか」という観点が重要です。
例えば、問題が発生した際に、まずどういう行動をとるべきかは、チームで共有されているでしょうか。トリアージ[1]は誰でも同じ基準で行うことができるでしょうか。こういった観点を突き詰めていくと、一言でIncident Responseといっても、実にさまざまな論点が含まれていることが分かります。
ここでは、他の各層の詳細説明は行いませんが、このように、各層で考えるべきことは多くあります。
サービス信頼性階層は、今後みなさんがSREとして信頼性を実装していくにあたり、どういった優先順位で物事を進めていくかを思考する手助けになるでしょう。
[1] トリアージ:事象の緊急度に従って優先順をつけ、可能な範囲で問題の影響を緩和すること。詳しくは以下を参照。
- クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション(後編)(Google Cloud Platform Japan Blog)
さいごに
本記事では、SREをはじめるにあたり考えることを整理しました。みなさんの会社でSREをはじめるご参考になれば幸いです。
「SREをはじめていきたい!」と感じた方は、ぜひ本記事の内容を参考に、SRE実践のロードマップを作成してみることをおすすめいたします。To-Beまでのロードマップを描き言語化しておくことはSRE実践に限らず、自分たちの現在地を見失わないために効果的です。言語化されていない内容はチームで共有が難しく、チームで共有できないことには向き合うことができません。
ロードマップを作成しながら分からないことがあれば、ぜひ本記事の筆者(@katsuhisa__)にご相談ください。
次回記事では、本記事でも登場したモニタリングやポストモーテムをどのように実装してくかの詳細を深掘りします。お楽しみに。