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