社内でSREの質問を受けることが多くなってきました。
これまで聞かれたことを一問一答として簡潔にまとめてみました（一部、長文になっていますが）。
今後も順次追加していきたいと思います。なお記載内容は、すべて個人的な意見となっています。属する組織や任意組織としてのとは見解ではありません。
また、筆者は、特段SRE詳しいわけでもないので、誤った回答となっている場合もあるので気が付いたらご指摘お願いします。
SREについて
(質問） SREとは
(回答)
Google が実践している、システムやサービスを高信頼に運用するための各種方法や仕組み。Googleは、そのノウハウをドキュメント化して公開しています。
このドキュメントを「SRE本」とこの記事内では定義します。
なお、SREのノウハウの方向性でインフラ運用を実施する要員をSREチームと呼びます。
(質問） 我々は、Googleじゃないです
(回答)
はい、その通りです。Googleは、世界最大・最強のシステムを構築していると考えると、SRE本のノウハウは、現時点でのシステム運用における最高のノウハウと考えることができます。当たり前のことですが、書かれていることをすべて理解して、取り入れる必要はないです。自分の気になる部分のみ参考にするとよいでしょう。
(質問) ぶっちゃけ、バズワードですよね？
(回答)
NoでありYesでもあります。バズワードのウィキペディアの定義に当てはめると以下のようになります。
-
日本語での意味は、もっともらしいけれど実際には定義や意味があいまいな用語のこと → No
- SRE本となっており、意味はあいまいではありません
-
英語では、特定の期間や分野の中でとても人気となった言葉のこと → Yes
* 2018/9現在、海外・国内とも話題となっている言葉です
GoogleがSREを広めれくれたことで、これまでSREに相当する高度な業務を行っていたにも関わらず、正当な評価を受けられていないエンジニアに陽の目が当たってきていると思います。
「働き方改革」という経営層にとって聞き心地のいい言葉よりも「SREエンジニア」へ正当な評価を！
** 2019/6 追記 **
InfoQ / DevOps and Cloud InfoQ Trends Report - February 2019 のレポートによると、 SRE は、 Early Adopter で2018年と変更ありません。ただし、編集者たちの意見の中には、Early Majority となっている（→キャズムを超えている）と言っている方もいます。このことから、バズワードから一般用語になってきているのではないかと思います。
(質問) 上司からSREやれと言われました
(回答)
やりましょう。どれだけの裁量が許されているのかわかりませんが、SREを「葵のご紋」「錦の御旗」として、改善・改革を進めてみましょう。
できるだけ、上司を巻き込み、周囲を巻き込んでいければベストです。
SREチームについて
(質問) 一人情シスなのですけど
(回答)
ひとりで各種サービスの安定稼働を実現していることは、本当に凄いことと思います。自身が行っていることを振り返り、SRE本に記載されていることはないか確認してみてはどうでしょうか。そのうえで、暗黙知、属人性を何らかの形で残していくとよいでしょう。可能であれば、苦労・工夫を様々なコミュニティやQiitaなど社外へOUTPUTしてみると新しい変化が得られるかもしれません。
(質問) 何から始めれば良いでしょうか
(回答)
自動化できるところがないかを検討してはどうでしょうか。
まずは、トイルの発見を進めてください。
(質問) SREを実践できるようなスーパーパーソンはいません
(回答)
各自、各メンバは、得意分野や不得手の分野があると思います。メンバ間で補完しあって行くのが理想的です。その中で、できるだけ暗黙知化せず、少しずつでもノウハウを共有していければよいと思います。まずは、SRE本の輪読を行う勉強会を始めてみてはどうでしょうか。
(質問) SREチームは、業務アプリケーション開発に口出ししてくるの？
(回答)
いい意味で積極的に口出しをしてきます。特に利用者視点での信頼性向上につながる提案をしてくれます。提案内容は多岐にわたることが考えられます。設計、実装、テスト、リリースのフェーズに関係なく、改善・改良ポイントを示し、場合によっては、プロセス変更も辞さない姿勢で迫ります。
ただし、開発チームと敵対するということではなく、最終的には開発チームにもメリットが得られる内容になるハズです。さらに、開発チームとSREチームは融合していくような体制にすると風通しがよくなってくると思います。
(質問) プログラミングスキルがほぼないのですけどSRE チームに入れますか
(回答)
システム運用を経験してきているのであれば、何か得意な領域があると思います。まずは、そこの専門家になる、という手があります。もしくは、SREを含めて広範囲のノウハウを俯瞰できるようなスキルを得て、様々な助言ができるようなこともよいかもしれません。
ただし、今後は、インフラ領域もIaC ツールを活用するために、コーディングをする必要がでてきます。目的意識をもって、何らかのツール・言語を習得してはどうでしょうか。例えば、AWS のCloudFormation の記述を覚えたり、IaC ツールの一つであるAnsible を動作させるPlaybook を覚えたりしていくことは、今後のスキルアップに必ず役に立つと思います。
(質問) 我が社は、そもそも自動化以前にシステム運用プロセスが適当なのですが
(回答)
プロセス改善から進めていくと、年単位の時間を要すると思います。陳腐ないい方になりますが、出来ることから、小さな事項でもよいの改善を積み重ねていったほうがよいでしょう。
(質問) 実は、SRE本の内容と似たようなことしている気がします
(回答)
日本の企業で稼働しているシステムでは、独自のノウハウによって高い信頼性を提供しています。特にミッションクリティカルと言われる金融機関システムや通信事業者向けシステムでは、SRE本に記載されている同じような取り組みをされていると思います。
サービスの受益者からは、高い信頼性でシステム運用が行われているということは、平常時にはまったく気にされることはありません。しかし、サービスが停止するような事態となって初めてシステムの存在を知り、サービス利用出来ないことへのクレームをあげてくると言ったことになります。
高い信頼性をどのように実現しているのか、Googleのように公開する価値は次の2点であると思います。
-
オープン化時代に沿って知識を共有
- 顧客情報やデータセンタの場所などは隠せば、SRE本のような情報を共有できると思います。これにより、システム運用のノウハウの共有資産化が出来て、業界の省力化に寄与できると思います。
- 取り組みを自主的に公開することでその企業の技術スキルを示すことができ、インフラ系技術者のモチベーションもあげることができるでしょう。
-
トラブル発生時に、どこの課題か、復旧までの道筋を示す
- トラブルの原因を含めすべてオープンにすることで、企業に対する信頼性が向上すると思います。
- gitlabの公開事例
- GitLab.com、200TB超のデータとともにAzureからGCPへ移行完了。三度の計画停止による予行演習を繰り返し、移行手順も公開
-
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット
- えらい人々がフラッシュを浴びながら、頭を下げる、といった「説明責任」より何倍も誠意があると思います。
これまでの考え方との関係性について
(質問) SoR システムを担当しています。SREって関係ないですよね？
(回答)
SoE (System of Engagement)でも SoR (System of Record) のシステムでも関係なく、SRE本プラクティスが参考になりますが、どちらかというとSoR色が強いかも知れません。
SoEシステムは、GoogleやAWSなどの各種サービスを使って実現することが多いです。そのインフラを支える巨大なGoogleのサービスはある意味SoR的な基幹システムだと思います。このようなシステムで高い信頼性を維持するためのノウハウがSRE本には記載されています。
(質問) DevOpsとの違い・関係は
(回答)
DevOpsの考え方を具体化したものと考えることができます。
SRE本をDevOps で検索すると、8件ヒットします。１章２項(1.2) には、「DevOps？それともSRE？」というコラムがあります。要約すると以下のような記述となっています。
「SRE本」引用・要約
「DevOps」は、2008年ごろから使われているが未だにその意味が固まっていない。
中核となるのは、以下のような事項
- システムの設計と開発の各フェーズへITに役割を持たせること
- 人手ではなく自動化を進めること
- システム運用においてエンジニアリングのプラクティスとツールを適用する
これらは、SREのプラクティスの多くと一致する。
DevOpsは、SREの中核的な方法のいくつかを一般化したものととらえることもできる。
同様に、SREはDevOpsの独自の拡張を少し加えたプラクティスととらえることもできる。
(質問) ITIL と関係ありますか
(回答)
直接的な関係はありません。SRE本内には、ITILの記述は一つもありません。ただし、ITILのベースラインを具体的事例で深く説明していると考えていいとは思います。
ITILは体型的に整理され規格化された書籍。システム運用の全体像に焦点を当てています。一方、SRE本はGoogleの社内ノウハウの一部のため、ITILプラクティスを網羅しているわけではありません。
日経SYSTEMS 2018/5号の特集記事「NoOpsがやってきた」には、システム運用保守のアプローチとして、「ITIL → DevOps → NoOpsへ 変わってきている」、「NoOpsの活動としてSREプラクティスを使用している」、と記載されています。この説明をクラス図にしてみると以下の左の図ようになります。SRE本の内容から考えると、右の図のような関係性ではないかと思います。
読み方について
(質問) ５００ページも読めない
(回答)
SRE本の「はじめに」の「本書の読み方」というコラムには、「本書は好きな順序で読めるようになっていますが、少なくとも２章と３章から始めることをおすすめします」 と記載されています。
自身の課題に該当する部分や、自分の得意分野から読むと良いでしょう。ただし、目次を見て、どのようなコンテンツが書かれているのか俯瞰はしてください。
(質問) 原書で読んだ方がよいでしょうか
(回答)
英語が堪能な方は、原書と訳書を見比べるとよいのかもしれませんが、この記事によると、機微な部分があり訳書で理解した方が良い と書かれています。
特に「第Ⅲ部実践」は、日本語でも何が書いてあるのかわからない部分が多く（個人の感想です）、原書ではアルファベットの羅列となると思います。
なお、2018年7月に公開されたThe Site Reliability Workbook は、訳書はまだありません。