運用本部長を務めている山本泰宇です。 運用本部は社内の情報システムを担当する情報システム部と cybozu.com など自社クラウドサービスを運用するサービス運用部からなる部門です。
本日、サービス運用部にて SRE チームを設立しました。この記事ではチーム設立にいたった経緯と今後の活動計画を紹介いたします。
Site Reliability Engineering (SRE) とは
今年の 3 月に O'Reilly から出版された "Site Reliability Engineering" で有名になりましたが、Google のプロダクトやサイトを安定運用するための活動やその活動に従事する人・チームを指します。特徴としては基本的にソフトウェアエンジニアからなる集まりで、自律的な仕組みや自動化を日常的に行っていることです。
サイボウズでも 5 月から社内で SRE 本の輪講を開催し、理解を深めてきました。中でも盛り上がったのは Chapter 5 "Eliminating Toil" です。簡単にいうと「通常の運用でオペレーターの操作を必要とするケースは、それそのものがバグ(不具合)である」とみなして「オペレーション」という綺麗な言葉ではなく Toil (骨折りとか苦労の意)と呼んで極力減らしていこうという内容です。
他にも Error Budget (障害があるたびに減っていき、枯渇すると新規リリースを停止するような取り決め)やパーセンタイルでの指標定義など実践的なノウハウに富んでおり、クラウドサービスの運用に関わる人は必読の一書です。
SRE チーム設立にいたる経緯
サイボウズは元々オンプレミスのパッケージ製品開発の会社でしたので、クラウドサービスのオペレーターはいませんでした。クラウドサービスの開発にあたっては、私をはじめ製品を開発していたプログラマがインフラの仕組みを構築しました。
cybozu.com のサービスイン前後までは、今でいう SRE チームのようにソフトウェアエンジニアが自律的な仕組みや自動化をがんがん整備して、日常のオペレーションは完全に自動化するような体制でした。
しかしサービスインからしばらくして、順調に顧客が増え、システムの規模も増加するにつれて簡単には自動化できないような対応が増えてきました。オンコール対応(障害発生時の緊急呼び出しのこと)をはじめ、各種の調査依頼や特殊な変更手順などです。多くは優先度の高い割り込み業務にあたります。
ソフトウェアエンジニアの生産性は割り込みがあると激しく落ち込むことが知られています。実際夜中の障害対応にあたったエンジニアがしばらく調子を崩す事例などが積み重なった結果、開発専門のチームとオペレーションを主務とするチームに分割しました。
しばらくは開発チームの生産性も改善しそれなりにうまくまわっていたのですが、最近では以下のように深刻な問題が出てきてしまいました。
開発したシステムの運用コストが甚大な事例が複数あった
稼働中のシステムの変更は、現システムからの移行手順が良く検討され自動化されていないと非常に困難なものになります。開発専門チームがそういったオペレーションまで想定できず、移行作業の人的負荷が多大になったりしました。
オペレーションチームのソフトウェア開発スキルが向上しない
開発専門チームがあるとはいえ、当初はオペレーションチームも時間があれば自動化等の開発をしていました。しかし時間が経ちオペレーションチームに新規配属されるメンバーが増えてくると、次第にオペレーション専門のチームに様相が変わってしまいました。
Toil が爆発しているのに減らせない
チームがわかれると、お互いの情報を知る機会も減ってしまいます。オペレーションチームが開発ではなく手順書を増やしていく(Toil が増えていく)状況であるにも関わらず、開発チームがそれに気付かず改善できないということが積み重なってしまいました。気付いたときには長大な手順書が営々と受け継がれている状況でした。
これらの問題が見過ごせない状況になったため、チームを再び統合し、SRE チーム設立の運びとあいなったわけです。
SRE チームの業務と今後の取り組み
これまでやってきたことも含め、サイボウズの SRE チームの業務内容を紹介します。
サイトの信頼性を保証するという定義の通り、サイボウズの SRE チームはサービスレベル目標（SLO）を踏まえた指標管理、セキュリティ対策や緊急パッチの適用、各種モニタリングシステムの開発・運用、ロードバランサや自社製 KVS の開発、データセンター間ネットワークの設計や各種ハードウェアの調達、更新など様々な業務をこなしています。現在は 1 万 5 千社以上の有償契約を抱え、一日のアクセス量は 1.5 億程度の規模です。
cybozu.com では稼働率目標 99.99% を掲げていますが、概ね達成できている状況ではあります。
とはいえ色々問題を内在しているので、新生 SRE チームは以下の方針を掲げて活動していきます。
役割を固定しすぎない
何年も開発専門とか、何年もオペレーションばかりといった役割の固定化は避けます。 Google のようにインシデント対応や問い合わせ対応は仕事の 50% に収まるように調整する、かどうかは分かりませんが、やり方を検討していきます。
ソフトウェア開発スキルを磨く
オペレーションチームの若手を中心に、ソフトウェア開発スキルを向上させる機会が少なかった点を改善します。既に私や他のプログラマが教師役として、トレーニングの時間を設けています。
Toil はなくしていく
長大な手順書も。絶対にやるという気持ちが重要だと思うので、明記しておきます。
We are hiring!
最後にお約束で済みませんが、SRE チームで活躍できる人材を大募集中です！ 職場環境や開発環境については以下の記事で紹介しています。
SRE の募集要項はこちらです。まずは話を聞いてみたいという方も大歓迎ですので、Twitter やお知り合いの社員を通して遠慮なくお声かけください。
それでは。
