SRE1チームの遠藤です。いうイベントの参加レポートと、エムティーアイSREチームの紹介記事です。Loungeの方々が開催されたSREに関する日本初のカンファレンスです。思っていたよりも来場者が多くSREの注目の高さを実感しました。(このサイズのセッションが複数行われました)セッション資料はこちらのQiita記事にまとめられています。Engineering)とは、Webサービスの信頼性に責任を持つエンジニア、またはそれらの行為を指す言葉です。信頼性と開発スピードのバランスを最適化するためにGoogle社内で生まれたものです。通称SRE本と呼ばれる書籍が出ており、日本語訳も出版されています。DevOpsという例えがよく使われます。DevOpsは文化的な話であり、SREはそれを体現する役割を指すのだと解釈しています。参考セッション:delyにおける安定性とアジリティ両立に向けたアプローチSREが実際にやることは、従来のシステム運用やインフラエンジニアと被るところが大きいです。運用に対する価値観やアプローチが異なります。運用は「障害を起こしたくない」という目標の違いがありました。このようなデメリットに対してGoogleがとったアプローチがSREです。ReviewSREの重要用語としてサービスレベルエラーバジェットが挙げられます。SREは「信頼性とは何か?」を定義し、サービスレベルを決め、それをDevとOpsの共通の目標とします。「機能開発を止めて信頼性向上に開発リソースを充てる」といったエラーバジェットポリシーを定めます。従来のDevとOpsの対立構造をなくしつつ、信頼性とスピードを両立させます。これらは、一見とても良いなと思えるのですが、SRENEXTに参加して、やはりこのエラーバジェット導入が最も難しいと感じました。文化的に受け付けられなかったり、SLOが適切でないと納得されないのではという懸念があります。導入にあたりマネジメント層のサポートも必須でしょう。実際に、会場でもSLOを設定しているのは10~15%、エラーバジェットポリシーを元に運用している方は1~2人でした。弊社SREチームは、システム運用部内で発足したチームです。このチームの一番の特徴だと思うのですが、エムティーアイはBtoC、BtoBに関わらず多くのWebサービスを運営しているため、1サービス1SREチームではなく、複数人で複数プロダクトを見るような形をとっています。私がいるSRE1チームでは、10近くのサービスを10名ほどで分担しています。障害発生時などは多少フレキシブルに動けるようになっています。エムティーアイSREの定義Googleや他社のSREを参考にしつつ、エムティーアイ流のSREを定義したのが半年ほど前です。保守フェーズのサービスをSREメインで省力・安定化させることです。技術志向なだけではなく、ビジネス視点を持って動けるエンジニアが求められているのだと理解しています。SREに求められる仕事やスキルセットは、その会社や現場の課題によって変わるため、そもそもの前提が異なってくるはずです。導入できそうなところ採用しながら独自のSRE像を描けると良いと思います。SREとDevOps外部の勉強会やカンファレンスに参加すると、「複数サービスを兼任するチーム体制は少し特殊かも」と感じることがあります。基本的には1サービス1チームとして動いている現場が多いのではないでしょうか。弊社でも単一のサービス専任のチームやDev/Ops一体型のチームは多いですが、どちらが良いとか悪いとかはなく、仮に部署やチームが分かれていてもDevOpsは可能だと考えています。多岐にわたるサービスを複数展開している場合、運用が一元化されていることは大きなメリットです。従来のシステム運用がやっていたようなルールや文化を共通化しやすいです。その現場ごとに適したDevOpsの形があります。文化、価値観、ツールやルールの違いなど、DevOpsを阻害する要因があればそれを改善していくのもSREの役目かなと思うようになりました。以下は、私のチームで実施しているSREっぽい活動の紹介です。サービスレベル策定SREチームが主導して各事業ごとに進めています。社内で1つ例ができるとそれに倣って進められるので、決めやすいサービスから始めると良いでしょう。社内サービスや、自社で完結するようなサービスは比較的導入しやすいはずです。できるところから導入して文化的に徐々に浸透させていきたいです。NEXTのセッションにもあったのですが、どれくらいのサービスレベルが適しているか、初めから定量化するのは難しいと感じます。決めてしまって、早めにログの集計と可視化を始めてから随時見直しをかけるのが良いでしょう。(「可用性99%は低いし、99.99%だと高い気がするから99.9%にしようか」くらいの温度感で良いのかもしれません)また、サービスレベルを決めて終わりでは意味がないので、データの収集と可視化をして、運用に組み込むところまで考えましょう。私の場合は、AzureのApplicationInsightsで取得したデータを元に、開発スプリントと同じ粒度で集計しています。LogicAppが便利なのでクエリの定期実行も自動化しています。トイル削減など運用負荷の低下トイルは、日本語で「労苦」という意味で、本質的に価値を持たない自動化できる作業のことです。サービスの成長に比例してトイルが増えることは、運用負荷に繋がるため、信頼性の低下を起こします。社内で使っている工数管理ツールとをBIツールを連携させて可視化を行いました。各トイルにSREメンバーをアサインして自動化に取り組んでいます。この活動はSREチーム内で定着し、ある程度の効果が期待できそうです。私の場合、よく関わるサービスが3つあり、AWS、Azure、オンプレミスを同じくらいの割合で触っています。CDK,ARMTemplate)やCI/CD(AzureDevOps)が整備されました。ブルーグリーンデプロイやゴールデンイメージによるリリースが可能になり、よりSRE的な業務に時間を割くことができるようになりました。Item」の略で、ITサービスを構成するあらゆる情報のことを意味します。オンプレ系システムの管理が煩雑になっており、サーバー情報を探すのに時間がかかったり、サーバー台帳の情報が古かったりという問題がありました。そのため、運用/SREメンバーを中心に、サーバー情報をWeb画面で一元管理できるツールを作成しました。これにより、IPアドレスやホスト名の確認OSやソフトウェアに脆弱性があった場合の影響範囲調査OSアカウントの棚卸しなどが一瞬で行えるようになりました。現在は、サーバー情報以外のCIとして、運用ドキュメントの整理と可視化に取り組んでいます。ポストモーテムインシデントについての根本原因の深堀りと再発防止の検討は以前から実施していました。障害の対応やその再発防止について、横展開しやすいというメリットがあります。監視アラート、オンコール対応、問題管理と再発防止実施など、文化的な面ではかなり成熟していると実感しました。セキュリティの対応を一律で横展開できることも強みです。今後サービス規模が拡大したときに比例して増えるトイルは何かという視点でした。採用技術、ツール、ルールの共通化など、サービスが増えた際にトイルを増やさないための工夫も必要だと感じました。窓割れ理論のように、重大な問題に発展する前に未然に防ぐ動きができるチームになりたいですね。js01.jposting.net弊社SREもまだまだ発展途上で、模索中です。コミュニケーションの活性化こんにちは。