この記事は、SRE Advent Calendar 2019 の 15日目の記事です。
はじめに
私はサイバーエージェントグループのサムザップで Enabling SRE をしているCatservantです。
SREチームを立ち上げてから約1年半が経ちました。振り返りも兼ねて経緯や成果についてまとめることで、SREsを始めようとしている人が自社でどう進めるかのお手伝いや、SREsについて興味ある人が増えるきっかけになればいいなと思っています。
SREチームの立ち上げ
現在サムザップのSREチームは、インフラチームのメンバー3人と元開発職の2人、とてもお世話になっている業務委託の方1人の計6人で構成されています。
2018年5月に、もともとインフラチームのメンバーを中心に、SRE（Service Reliability Engineering）チームとして活動を始めました。（多くの会社ではSREは Site だと思うのですが、うちはゲームを作っているのであえて Service です。）
理由は大きく分けて二点になります。
1. チームの役割が変わったので、名称を業務(役割)に合わせました
インフラチームと言えば、サーバの保守など運用のイメージが強いと思います。
しかし、パフォーマンス改善とセキュリティ強化などサービスの信頼性を向上させることが中心であり、それを今後も継続・強化していくため、業務内容とチーム名を合わせました。
2. チームの役割を明確にすることで、社内の信頼性に関する意識を向上させる
サムザップが提供するサービスの信頼性を向上するというチームの役割を浸透させ、その取り組みに会社全体を巻き込んでいきたいと考えました。
SREというチーム名がそのまま役割となっているので、分かりやすいという思いもあります。
サービスの信頼性を向上する業務ならば、社内を巻き込みながらなんでも行うという能動的な業務スタイルを取るチームがサムザップに誕生しました。
SREチームの長期的な目標
ここが他社のSREチームと異なるかもしれないと感じています。
弊社のSREチームでは最終的にSREチームがなくなることがゴールとなっています。
この言い方をしてしまうと語弊があるかもしません。
SREチームがなくても、開発メンバーを含めたプロジェクト全体が信頼性について常に考えて実現しているといいなという、プロジェクトとの融合をすることが最終目標になります。
SREチームで行った取り組み
業務と成果以外にも、今SREチームが成果をあげている要因となったと思われる施策をまとめてみました。
1. チーム合宿
チームの目標や行動指針、メンバーの相互理解のための時間を作った
お互いの考えや人間性などを知ることができ、メンバーの意外な一面を発見したり、良いところを再確認したりすることができました。また、チームとしての方向性や目標などを決めることができたのも良かったと思います。今年は２回目の合宿を行い、その効果を再認識できました。
2. 行動指針の制定
チームで業務を行う際の行動指針を制定しました。
（https://www.cyberagent.co.jp/techinfo/info/detail/id=20764 SGEのエンジン）
目的は業務を行う方針を決めることで、大切にしたい価値観をチームで共有することです。また、冊子を作り常に携帯することで、心に留め置くことができるようにしました。
【サムザップ SRE の行動指針 SREngine】
UXファースト - 対ユーザ向けのサービスを運営していることを忘れずにシステム面でもユーザの体験を第一に考える(お問い合わせのシステムや、ゲームのレスポンスなど)
オープンなチームであれ - クローズドなイメージが強いSREチームだからこそ情報は常にオープンに。プロジェクトに寄り添い、現場と融合するチームを目指す
その技術はイケているか？ - 最新の技術動向をとらえ、今あるシステムを常に見直し、導入コストやメリット・デメリットを考え抜く
1人プレイ禁止 - SGEエンジニア行動指針である「エンジン」に準拠。1人で考え行動するのではなく、組織に所属して働いている意味を考える
ムチャをしない - 行動を起こす前にスケジュールを立て、常に最悪の状態を想定し冷静であれ
感謝されるチームであれ - 多くのチームと関わりシステマチックな解決に導く。また他チームの方にもチーム価値を正しく知ってもらうように努める
SREチームで行った業務
リリースまでの間の構成管理、障害試験、負荷試験、開発環境整備、CI/CD整備、セキュリティの担保、ログ集約基盤も含めたサイドサービスの構築管理、プロジェクトからの要望に答えるなど、様々な業務を行っています。立ち上げからの1年半で多く効果をあげた成果についてまとめました。
1. 既存サービスをオンプレミスからパブリッククラウドへ移設
これについては、AWS Summit 2019 で発表しているので、そちらをご覧ください。移設により、リクエストに対する平均レスポンスタイムが1/3に、コストが1/2に、さらに業務効率も向上しました。
https://pages.awscloud.com/rs/112-TZM-766/images/L3-01.pdf
2. クラウド技術及び業務の標準化
terraform と ansible などによる構成管理の標準化を行い、誰が担当しても偏りがなく業務が行えるようになりました。これを進めてくれたメンバーのおかげで、新規プロジェクトにおける業務効率がかなり向上しました。とあるメンバーの構成管理にかかっていた数時間が数分になるという劇的な変化がありました。
3. 中長期また次のプロジェクトを見据えた技術の検証と導入
AWSなどのパブリッククラウドは日々アップデートされていきます。新しいサービスやインスタンスクラスが発表されたり、既存機能がより便利になったり、その恩恵を享受するために、課題をまとめて改善する目標を立てています。
標準化の一環でもありますが、リスクをあらかじめ予測した上でその対策を先回りして考えておくという信頼性の向上にはとても大切なことだと思います。
最後に
こうして振り返るとあっという間の1年半だったと感じます。移設も含めて、新規プロジェクトのリリースなど大きなイベントがありました。最近情報公開となったプロジェクトもあり、会社として挑戦し続けているフェーズになります。
その中で、サービスが安心してリリースできるという社内に対する信頼性、サービスを安心して遊べるというユーザに対する信頼性など大事にしたいと考えています。運用プロジェクトもこれからリリースされるプロジェクトも、SREチームの１員としてさらに貢献できるように頑張ろうと思いました。
SREチームの業務は多岐にわたり、インフラエンジニアと呼ばれている職種と比較すると非常に幅が広くなっています。SREだから... 開発メンバーだから... と職種にとらわれることなく、信頼性が上がるならなんでもやるというスタイルで仕事ができる環境と体制を作れたことで成果が出やすくなっているのかなと思います。
1月に行われるSRE NEXTのスポンサーになっており、弊社から2名参加予定ですので、来場される方、また懇親会に参加される方はぜひお声掛けください。
16日目は https://qiita.com/valerauko さんの記事になります。