無気力生活 (ノ ´ω｀)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

SREをどう始めるべきか？のヒントを貰った一日について

えらく遅い投稿となりましたが、2019/01/18(金)に開催された、SRE Loungeに参加してきました(｀･ω･´)ゞ sre-lounge.connpass.com

f:id:gdgd-shinoyu:20190121032208j:plain:w400
フードがうまい

金曜日の19:00開始というスケジュールでしたが、ほとんど席が埋まってました。実際にSREを運用している企業の事例を聞いたり、懇親会で盛り上がっていろんな会社さんと話をしたりしていましたが、かなり面白い話が聴けて、3時間あっという間でした。

講演中の資料は以下です。公開していただき感謝。

speakerdeck.com

speakerdeck.com

※Speee天野さんの資料は見つけられなかった(´・ω・`)

詳細は資料を見ていただくとして、参加して私が感じたことや考えたことを書いていきたいと思います。

SREとはなにか？の理解

まずはSREとはなんぞや？的な話を私の理解でまとめてみます。SREと聞いてほとんどの方はこの本を思い浮かべると思います。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Google社で昔から様々なサービスを提供し蓄積してきたベストプラクティスをまとめた本です。SRE本はGoogle社の事例であり、取り入れる企業の状況によって、SREでやるべきことは異なります。

しかし、SREを進めるときの考え方はおそらくどの企業でも共通だと思っていて、私個人的にはこのような認識を持っています。

「サービスを安定させて、顧客に最高のユーザー体験を提供し続ける」

これまでの開発・運用と大きな違いはなく、唯一違いがあるとすれば、「何をもってサービスを安定していると言えるのか？」を定量的に評価し、運用で得た知識を共有することを強制することにあると思うわけですね(｀･ω･´)

そのためにはまず、顧客に提供すべき基準であるSLA(サービスレベル契約)と、プロダクト側の目標値としてのSLO(サービス レベル目標)を定義します。合わせてSLOを評価するためのSLI(サービスレベル指標)を決めます。一般的には可用性やレイテンシがよく使われるかと思います。

目標値やそれを計測するための指標が決まると、エラーバジェット(許容できる停止時間)を算出できるようになります。例えばSLOが可用性99%で評価される場合、1%は「機能リリースのために使っていい停止時間」として扱えます。システムの信頼性を100%にするのは難しい、ならば許容できる範囲を決めてそれを守ればいい。

....始めて触れる考え方で、いい意味でショック受けました。使っていい停止時間が見えることで、気持ち的に余裕が出てくるのはいいですね。失敗しても基準値中に収まる、これが認識できるようになると必要以上にリリースを怖がることがなくなり、新機能や後述するToilの削減をガンガン反映していくことができます。

とはいえ、実際に障害を0にすることはできず、起きるときに発生してしまうのが奴らです。SREの文脈では、ポストモーテム(障害報告書)を”正しく”運用します。障害を失点と考えず次の学びとする。そのために発生した障害についてかなり詳細に記述する必要があるようです。

  • 発生したこととその影響範囲
  • その緩和や解消のために行われたアクション
  • 根本原因
  • 再発防止策

これらの情報を元に、発生した問題を集合知に変えたりシステム自体を改修するなどして、次回同じ問題が発生することを防ぐ活動をします。単にお偉様に報告するだけの資料ではなく、その後の改善を主目的に行う。当たり前に行っていきたい考え方ですね。

そしてSREといえばToilが多く語られます。定常的な運用作業、という体で扱われていることが多そうですが、ぱっとイメージするのは度重なる不具合調査とか、ぬくもりある手作業リリースといった運用のめんどくさい作業。こういった作業を自動化したり、そもそも運用を変えたりしてToilを削減していき、本来のプロダクト開発に使う時間を確保することが求められます。SRE本のGoogleの事例ではToilの作業を全体の50％以下に制限するルールだったそうです。後の50％は顧客価値向上のためのプロダクト開発に使う。

そもそもToilはいびつな運用を行っているために発生するもの、と私は思ってます。自動化してワンポチでリリースできれば一日に何回もリリースを行うことが可能だし、障害を発生させない仕組みに変更することでそもそも障害調査をする必要がなくなったり。 プロのエンジニアとして働いているのであれば、少ない労力で最大の効果を上げるよう振る舞うのは義務です。そのためにもToilを発見し、倒していく。継続し続ければ顧客価値向上の速度が更に上がり、ビジネスの結果にも繋がるでしょう。

感じたこと

SREを実践している3社の話を聞きましたが、やはり各社によって捉えかた違ってましたね。 メルカリさんでは事業の成長に沿ってSREを進化させ続けることに関心が多くあったり、一方グノシーさんでは、SREとは何で何をもって評価するのか？に関心が寄っているように感じました。SpeeeさんではSREを実践する組織づくりやメンバーの評価を見ているようで。

各社とも要求される品質も、必要とされるスピードも異なっているので当然のことなのですが、SRE本に忠実に運用するより何が自社にマッチしたSREなのか？を意識した上で運用を検討するほうが、よりワークするかと感じています。

弊社でもSREを導入したい、といった声は度々上がっており「弊社のSRE」を実践した後に、成果をこの場で発表できるようになるとGoodですよね(｀･ω･´)がんばります。

心の声

懇親会の話題

懇親会は他の会社の方と結構話しました。

SREを運用している会社の方は全体の3-5割ほどでしょうか。これから導入し始めたい、といった弊社と近しい状況の方も多く話が盛り上がったのですが、経験者が少なくやり始めるのが大変という状況が伺えました。登壇して発表された方でもSRE経験者の採用に苦労している旨の話があるらしく、少ない人数でなんとかうまく回している、状況が実情なんだろうなーと感じました(´・ω・`)

新人を育成する、といった意見もありましたが、SREの領域だとエンジニア経験がかなり問われる気がします。障害のニオイや、対応の勘所といったスキルはある程度修羅場をくぐってこないと身に付き難いものですし。経験者を付けてOJTするにしても長期を見据えないと大変そうだなーという印象です。

後、記憶に残っているのは、SREエンジニアの評価をどうするか問題がありました。 もともとインフラ寄りの仕事である以上、どうしても正常に運用が回っている状況では必要性が感じられ難くく、評価し辛い話が生まれそうです。解決する手段として、SLOやSLIといったように今の品質がどうかを計測し、評価者に定量的な数値を元に評価してもらうことが可能になります。

「俺がいるからこの目標が達成できている」を自信持って言えるようにしっかり測定して追っていく。正しく結果と評価を結びつけることも大切ですね。



他にもいろいろと考えたことや書きたいことがありますが、今日は一旦このへんで(｀･ω･´)