エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

SRE Lounge #9 で弊社の取り組みについて話しました

こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。

5/29に開催されたSRE Loungeというイベントで「エムスリーはどのようにしてSREをはじめたか」というタイトルで登壇させていただきました!

登壇の場を提供していただいたSRE Lounge運営スタッフの方々、スポンサー&会場提供していただいたサイバーエージェントさん、ありがとうございました。

本記事ではイベントの簡単なまとめと、時間の都合上語れなかった弊社の他の取り組みを少し書いていきたいと思います。

f:id:tshohe:20190605102051j:plain ANA Lounge Haneda by LWYang is licensed under CC BY 2.0

SRE Lounge について

各社のSRE実践例などが聞けるイベントです!

イベントページ sre-lounge.connpass.com

今回のページ(第9回) sre-lounge.connpass.com

各社の発表まとめ

DIPのSREの活動とこれから

speakerdeck.com

dipのbayashi_okさんの発表です。
これまで外製で構築してきた規模の大きいサービスを内製化していく中でどのようにSREとして活動されてきたかをお話されていました。 Git + Ansibleでコード化する文化がない状態から、処理フローを定義し展開していったそうで、とても大変そうだなと思いました。 また速度改善チームというものも立ち上げ、FastlyのImageOptimizerを用いた性能改善を実施した結果、応募率の大幅な改善にも繋がったそうです。(こういった性能改善の効果を測定できているのも、とてもいいなと思いました)

タップルSREの軌跡と描く未来

www.slideshare.net

サイバーエージェントの袴田さんの発表です。
足元の課題だけ対処していても事業成長への貢献度が先細ってしまうので、3年後の理想像/中長期戦略といったものを経営層/開発関係者の合意を得ながら進めているということでした。 また開発組織が抱えるリスクをスコア化する取り組みはとても興味深かったです。(ちなみに障害毎のスコアは問い合わせ件数で決めているそうです)

エムスリーはどのようにしてSREをはじめたか

speakerdeck.com

どのように各サービスのSLOを決定し監視を始めていったかについて話しました。
ちなみに何箇所か引用させてもらったThe Site Reliability Workbookですが、社内で輪読会を毎週開催して読み進めている最中だったりします(現在16章くらい)。 ボリュームは結構ありますが、様々な実践例が載っていてとても参考になります。

https://landing.google.com/sre/workbook/toc/

登壇発表の中で語りきれなかった取り組み

On-callシフト

長らく気づいた人が障害対応するという暗黙ルールの上で各自が対応していたのですが、明確にOn-call担当をつけるようにしました。
担当は週替りで交代するようになっており、PagerDutyの通知先をBotでローテーションするようにしています。

  • 主担当: 重大な障害発生時に発報
  • 副担当: 主担当が電話に出なかった場合、5分後に発報

また弊社のサービスの負荷は8時前後にピークを迎えることが多く、通勤時間とかぶらないようにSREの誰かが会社に到着したのをSlackで確認してからOn-call担当者が出勤する、というようなルールを追加しています。

Toil削減の取り組み

下記のような流れでToilを潰していきました。

  1. 定形作業をSpreadsheetに列挙
  2. 各作業の時間をざっくりとTogglで計測
    • Toilとなる作業依頼を受けたときにJIRAにもチケットが作成されるようにしており、そのチケットが進行中ステータスになっている時間で測れないかと試してみたこともありましたが、こまめにチケット移動するのは大変で漏れも多く精度はイマイチでした...(作業種別ごとの中央値 x チケット数とかにすれば安定するかもしれません)
  3. 頻度 x 時間が大きいものから自動化を検討

自動化方法としてはJnekins, Ansible AWXといったもので行っており、各ジョブの実行権限をサービス側に付与しています。

Ansible AWXであれば操作をAnsibleで実行できるため、シェルスクリプトに比べて冪等性のある操作がさせやすいかと思います。
しかし、Jenkinsのように入力してもらったパラメータに更にシェルスクリプトでいじる、というようなことがやりにくく、痒いところに手が届かないケースもあったりします...。

まとめ

他社のSREとしての取り組みを聞くことができ、様々な知見を得ることができました!
SREの方、またはSREに興味があるという方はぜひ参加してみては如何でしょうか。

We are hiring

ということで、資料にも書きましたがまだまだ手探り状態...ということで、一緒に悩んでくれるSREを大募集しております!!
ご興味のある方は、下記リンクからお問い合わせ下さい!

ちなみに、最近では全チームを横断的に見るSREだけではなく、各サービスチーム内でSRE的役割を担ってくれるエンジニアも募集していたりもします!

jobs.m3.com