SREとして意識している3つのこと
株式会社ラフールでSREをしている伊藤です。弊社の技術的な取り組み等を理解してもらうために、不定期ですが技術的な事を書いています。
※SREとは、Site Reliability Engineer（サイト信頼性エンジニア）の略称で、サービスやインフラの信頼性を支えているエンジニア。
前回の記事はこちらです。簡単ですが私のプロフィールも記載していますので、興味のある方はぜひ一読していただけると幸いです。
今回は私がSREとして意識している3つのことを紹介させていただきます。
ちなみに、この後の文章で『SRE本』という表記が何度か出てきますが、こちらは、GoogleのSREメンバーが執筆した書籍で、SREのバイブルとも呼んでも過言ではありません。（気になる方はぜひ購入してみてください。安くはないですがSREを目指す方は必読の書だと思います）
まず1つ目！
その1 とにかくコード化
従来のインフラエンジニアという枠組みではあまりコード化（ソースコードとして管理する）について重きが置かれていませんでした。しかし、SRE本にも書かれていますが、SREとコード化は切っても切れない関係です。
これはSREがアプリケーションのコードを書くという意味ではなく、SREが行うオペレーションをコード化することで効率化するという意味です。
具体的に何をコード化するかと言えば、クラウド上でのサーバー新規作成作業や障害発生時の復旧作業だったりします。
なぜ私がSREとしてコード化を意識しているのか。それは以下のメリットがあるからです。
・インフラの構成情報が可視化される。
・バージョン管理システム（VCS）の管理下に置くことで、更新履歴が追える。
・自動化が容易になる。（というか自動化の前提）
しかし、昔はインフラの設定作業等をコード化できる状況ではなく、インフラの設定変更を行うには管理画面からポチポチと作業する必要がありました。ところが、最近はクラウドサービスやコンテナの利用が当たり前になり、TerraformやAnsible等の設定情報をコード化するためのツールが登場し、各種SaaSサービスがAPI接続できるようになったことで、インフラ関連をコード化できる土台ができ上がってきました。やっと時代が追いついてきたのです。
SREにおいてコード化を重要視していることは、人材採用や技術選定の面で大きな影響を与えています。
人材採用面では、プログラミングの適切について採用面接のタイミングでは必ずチェックするようにしています。もちろん、開発メンバーのようにフレームワークを熟知していたりDDD（ドメイン駆動設計）を習得している必要は無いですが、プログラミングに苦手意識が無く、オブジェクト指向等の基本的なプログラミングに関する知識を備えていることがSREとしては望ましいと考えています。
技術選定面では、選定候補のツールやサービスがプログラマブル（programmable：プログラム可能な）かどうかチェックするようにしています。クラウドサービスの選定であれば管理用のAPIが提供されていたり、Terraform等のツールが対応していること、外部サービスの選定であればAPIが提供されていることが重要な要素となります。
SREとコード化は切っても切れない関係ですので、SREとして最前線で戦うために私自身も日々プログラミングスキルの向上に努めています。
続けて2つ目！
その2 とにかく見える化
SREとして動き出すにあたり、まず最初にベースラインとして何かしらの指標を決めてトラッキングするようにしています。指標として多くは稼働率を採用することが多く、具体的にはサービスが正常稼働していた時間や正常なレスポンス数の割合を指標として採用します。
なぜ見える化を意識しているかというと、改善活動を進めようとすると、少しでも早く目に見える形で効果を得たくなり、すぐに手を動かしてしまいがちですが、まず最初に指標を決めてそれを見える化しておかないと後々改善したけど効果がよくわからないという状態に陥ってしまいます。
AWSやGCPのような主要なクラウドサービスを使っていたり、Mackerelのようなモニタリングサービスを使っていれば容易に稼働率を見える化できます。もしそれらのサービスを使っていなかったとしても、ちょっとしたスクリプトを作成し、定期実行させることで稼働率を記録することはできるかと思います。
見える化ができれば、後はそれを適宜チェックしながら施策の実行と振り返りを繰り返すことでシステムを進化させることが可能になります。
余談ですが、私も社会人として十数年になりますが、見える化が出来ていない現場（インフラに限らず）は意外と多いので、「あ、見える化できていない！」と気付いたら、積極的に見える化していきましょう。
最後に3つ目！
その3 開発チームと異榻同夢（いとうどうむ）
『異榻同夢（いとうどうむ）』とは『同床異夢（どうしょういむ）』の対義語で「場所は違えど同じ夢を見る」という意味の四字熟語です。
SRE本でも触れられていますが、旧来は開発チーム（Dev）と運用チーム（Ops）の間では利害関係が一致しないことが多く、開発チームはいかに早く新機能をリリースするか、運用チームは極力余計な変更を加えることなくいかにサービスを安定稼働させるかという衝突が発生しがちです。同じサービスに携わっているのに目指す方向が違う、まさに「同床異夢」の状態です。
この衝突が絶対ダメというわけでは無いですが、SREのあり方としては「サービスを安定稼働させること」と「少しでも早く新機能をリリースすること」でバランスを取ることを求められています。
バランスを取るにあたって個人的に重要だと思うポイントがSRE本で提唱されています。それは「稼働率100％を目指さずに一定のエラーを許容する」ことです。一定のエラーを許容することで、必要に応じてシステムを停止して稼働率を同じ水準にキープするための改善を加えたり、多少の犠牲を払うことで新機能のリリーススピードを最大化させることが可能となります。
運用の観点だけで見れば、稼働率99.9％（年間ダウンタイム約9時間）より99.99％（年間ダウンタイム約53分）の方が当然良いですし、100％であれば最高の状態です。しかし、稼働率を1桁引き上げることはそんなに容易いことではなく、それ相応の改善工数とコストを要します。あるいは新機能のリリースの頻度を下げないといけないかもしれません。
サービス全体で見た場合、稼働率の最大化だけを追求することは『売上ー費用∝利益』という関係式の中で、費用を必要以上に増大させてしまい、利益を圧迫するか、売上が伸びずに結果的に利益が少なくなるかしてしまい、結果的にサービス全体としては失敗となる可能性が高くなってしまいます。（もちろん稼働率を軽視しているわけではありません）
ですので、SREとしてはこのバランスを意識しながら日々の業務を行うことを強く意識しています。
まとめ
今回は私が担当しているSREのポジションについて普段意識している3つのことをざっと紹介させていただきました。SREは様々な観点で全体を俯瞰してバランスを意識する必要があると考えて、常に業務にあたるよう心がけています。（全てのポジションでそうかもしれませんが・・・）
拙い文章となってしまいましたが、最後まで読んでいただき誠にありがとうございました。次回記事も読んでいただけると幸いです！
この記事が気に入ったらサポートをしてみませんか？