SRE をやることになった

SRE というポジションを（兼務で）やることになりました。ほとんど何も知らないのでざっと調べてみるっていうアレです。

原典

Google で生まれた SRE チーム。その SRE チームが書いた本です。 SRE 本としてはこれが教科書っぽいですね。

こちらはもう少し実践的な内容になっているようです。

適当にググって見つけた記事で雰囲気を掴むやつです

SREってなんだ？哲学と習慣、そしてツール。という記事を読んでみる

SRE ってのは重要だしこれから需要も高まっていきそうだって話にはじまり、じゃあ SRE にとっての成功とは？　どんなことを習慣にする？　使えるべきツールは？と SRE の概要について書かれてます。

基本的な目標は「システムの規模が拡大しても、手動による介入を少なくして信頼性を高める」ことにあります。

スケーラビリティとは「自動化」に要約されます。数十のフットプリントから数百または数千のフットプリントへの移行方法はどのように変わるべきでしょうか？それは自動化しましょう、という言葉に要約されるのです。

自動化する、
そして、リソース管理・セルフサービスプロビジョニングなども重要であると。プロセスとツールも標準化しないとねっていってます

バランスがどうであれ「必要充分な」から「卓越した」というスキルレベルを区別するには、多くの場合技術的な専門知識を補完する習慣と特性の組み合わせによって実現されています。

成功するSREは、物事をより高いレベルで理解および解釈できる人です。なにがしかの変更は、その瞬間だけでなく将来のリスクや影響を引き起こす可能性があり、優れたSREはその変更を行う前に徹底的な分析を確実に実行します。

人々がしている非効率的で時間のかかることを発見し見つめ直し、今すぐこれを自動化して他の誰かがこの苦痛な作業を続けることを止める、それも SRE の役割です。

SREはチェンジ・エージェントになる

SRE が使うツールは次のようなものがあるようです。このリストを見ると業務範囲も見えてきますね。

計画 – アジャイルプロジェクト管理、トラッキングツール
開発 – IDE、エディタ、GitHub
確認 – CI/CD ツール
パッケージ – ビルド、パッケージング、リリースステージング、承認プロセスを管理するツール。Rake や JFrog
リリース – アプリケーションのリリースとライフサイクルを管理する
構成 – Terraform や Ansible など。コンテナの使用が増えるとこれらのツールの必要性は減少する。Docker などのコンテナプラットフォームや Kubernetes などのオーケストレーションサービスが不可欠になってくる
監視 – ログまたは分析データでアプリケーションおよびインフラストラクチャからメトリクスを収集し、ダッシュボードを介してデータに関するアラートを収集する

信頼性を高める仕事ということですが、その信頼性を測る指標は次のようなものがあるようです。

SLO, Service Level Objective – サービスレベルの目標。サービスの可用性が99.9%とか。常に SLO を超えているならリスクをとれるし、SLO を満たしていないのであれば一時停止して信頼性に集中したほうがいい。
SLI, Service Level Indicator – サービスレベルインジケータ。エラーなしで200ミリ秒いないに正常に完了したユーザクエリの割合とか。
MTBF, Mean Time Between Failure – 平均故障間隔。障害と障害の間隔。大きい方がいい
MTTR, Mean Time To Resolution – 平均修復時間。障害から復旧するまで。小さい方がいい
MTTD, Mean Time To Detection – 平均検出時間。障害発生から検知するまでの時間。小さい方がいい

ということで SRE の概要について勉強中です。

いまのところ安定稼働が鍵っぽいなと思ってます。自動化してスケーラビリティを高めること、障害時にいかに迅速に対応できるかですね。

これからは次のようなことを調べて行きたいなと思ってます。