##まえがき
この記事は iRidge Advent Calendar 2018
の19日目です。間違いなく。
##TL;DR
ソフトウェアエンジニアが運用業務に携わって行き詰まった時にSRE本が役立った事例の話。
※この記事で出てくるSRE本とはこちら
##あらすじ
@orfx は実務2年ほどのソフトウェアエンジニア (サーバーサイド)。
一般的なウェブサービスならなんとなく運用できる程度にインフラ面の知識はある。
が、低レイヤーの知識は乏しくインフラエンジニアを名乗るには程遠い存在。
そんな人間が自社サービスの運用チームにアサインされたからには人一倍頑張らなければならない、、、！
##はじまり
運用チームにアサインされて最初の任務が インシデント管理 の引き継ぎ。
その会合でチームに古より伝わる インシデント定義 と呼ばれる表を託される。
端的に言うとインシデントの重大度や対応優先度をあらかじめ定量的に定義しようとしたものだ。
###(例) インシデント定義のイメージ
| 機能 | 判定対象 | Aランク | Bランク |
|---|---|---|---|
| コンポーネント1 | 5xxエラー | 1件 | - |
| コンポーネント2 | 5xxエラー | 10件 | 1件 |
| コンポーネント3 | 5xxエラー | 100件 | 10件 |
また インシデント対応フロー と呼ばれる資料ももれなく付いてきた。
こちらも端的に言うとランクによって報告経路・頻度と対応期限を取り決めたものだ。
##迷走
このインシデント管理の資料や運用の見直しが次に着手する業務である。
運用業務の実状と合っておらず、定義に当てはめると対応が過剰になってしまうケースがあるから良い方法を考えなければならない。
先述の例でいうとコンポーネント1のような定義のことである。
が、しかし運用経験が浅い @orfx はどこから手を付けていいか分からない。
それ以前にインシデントという言葉が意味することがよく分からなくなっていた。
- ITサービスマネジメントにおける定義
- インシデント
- サービスの中断又はサービス品質の低下を引き起こす、あるいは引き起こす場合がある、サービスの標準オペレーションに含まれていないあらゆるイベント
「インシデントを定義するってこう言うことではないのか・・？？」
「他にも用語の使われ方が資料によって微妙に揺れていて訳が分からなくなってきたぞ・・・」
「インシデントってなんだ・・・？🤔」
##出会い
そんな中、答えと救いを求めてひたすらにググり続けている時に下記の記事を発見する。
「SRE?そういえば先輩の前所属チームがSREだったな・・・」
そして @orfx は偉大なる先輩からSRE本を受け渡されたのであった。
Google では、可用性を過度に高めないようにするため、一部のサービスで定期的にダウンタイムを実施するようにしています。Google の Marc Alvidrez は SRE 本の中で、内部ロック システムの Chubby について語っています。
(https://cloudplatform-jp.googleblog.com/2017/02/availability-part-deux-CRE-life-lessons.html)
「意図的にシステムダウンさせて顧客からの過度な依存性を排除する・・・だと！？」
インターネット界の巨人から放たれる圧倒的スケールな一文は自身の固定概念を木っ端微塵にされた。
それから電子書籍版を自費でポチるまでにそう多くの時間は掛からなかった・・。
##糸口
SRE本を読み進めるとある考えが頭に浮かんでいた。
インシデント管理という言葉に業務要素を詰め込みすぎているのではないかと。
Googleの信頼性を支えるエンジニア達は関連する内容を少なくとも下記３つの章に分けている。
- 4章 サービスレベル目標
- 14章 インシデント管理
- 16章 サービス障害の追跡
「賢者達ですら分けて考えている内容を凡人中の凡人の自分が一度に整理できるわけがないっ・・！」
そしてサービスレベル目標が明確でないことが最初に解決すべき課題だと確信して、各コンポーネントのSLI/SLO定義に着手し始めたのであった・・・。
##強引なまとめ
- 運用業務においてもフレームワーク的なものは重要でSRE本がその役目になり得る。
- スクラッチ開発でいう神クラスのように、定義が曖昧で便利な言葉があると過剰に役割を持たせ過ぎてしまう。
- フレームワークを取り入れるとベースとなる設計があり、知見など情報量も多いので引き継ぎコストが削減できる。
- とはいえ現時点で体系化されてはないので盲信できる訳では無い。
- SRE本は経験の浅いエンジニアでも運用入門書のように役立てられる。
- SREの全てを導入する必要はなく、やり易い所から取り入れていけば良い。
- 運用業務に行き詰まった時のヒントとなる可能性がある。
##あとがき
4年半振りのQiita投稿が技術要素皆無のポエムになってしまい誠にごめんなさい。
SREの考え方を実務に取り入れた事例は小さなことでもすごく参考にさせて頂いていて、今回のSREに触れるキッカケの話でも誰かのヒントになれば幸いです。
具体的に起こしたアクションの話もまたどこかで紹介できれば良いなと思います。
最後までありがとうございました！