SRE サイトアビリティエンジニアを読んで, 3
tamagawa ryuji さんが最後にイチローの言葉を借りて書いてましたが
「小さいことを積み重ねるのが、とんでもないところへ行くただ一つの道」
まさにこの言葉を身に染みて生きていきたいですね
今回は、僕のメモなので章の根幹を書いてなかったりするのでスミません
12章 効果的なトラブルシューティング
注意すべき落とし穴（まあまあ改変）
よく、トラブルシューティングで原因が見つからず悩むことが多い
下記事項を読み、再度自分に問いかけるようにしたい
・関係のない症状を見てしまったり、システムのメトリックの意味を取り違えてしまったりすること
・検証用のシステムやシステムへの入力、環境の変更方法を誤解している
・仮説の間違い、過去起きた原因に固執する
・偶然発生した事象、間違った関連性の追求18章 SREにおけるソフトウェアエンジニアリング
「ソフトウェア開発の取り組みに対する信頼を構築するのは長い時間がかかりますが、過ちを犯して信頼を失うのはごく短い時間しかかからないので」
どの業界でもそうですが、信頼はすぐ失ってしまうものですよね
22章 カスケード障害への対応
カスケード障害とは？ 時間と共に拡大していく障害のこと
ケースとしては「サーバーの過負荷」「リソースの枯渇」などがある
リソースの枯渇による二次的効果
CPU枯渇
> 処理中のリクエスト数の増加
> 長すぎるキュー
> スレッドのスターベーション
> CPUあるいはリクエストのスターベーション
> RPCのスターベーション
> CPUキャッシュの効果の低減
参考資料：GoogleのSREの本「第22章 カスケード障害への対応」を読みました。
まずスターベーションとはなんぞや？
飢餓のことを言うですね ＝＞ Starvation
恐らく、苦しくなっていく様を表しているので翻訳せずに「スターベーション」をそのまま使っているのかなと
ロック待ちで進められないスレッドなどでヘルスチェックができなかったり
CPU・リクエストのスターベーションによりサーバーがクラッシュしたりします
メモリの枯渇
> タスクの死
> Javaにおけるガーベージコレクション（GC）の増大と、それによるCPU使用率の増大
> キャッシュヒット率の低下Javaにおけるガーベージコレクション（GC）の増大と、それによるCPU使用率の増大 →こちらは実際体験したことがありまして、JVMのGCの回数が増大（波形の上がり下がりが大量）して、CPUが150%（クラウドだからね）超えデータ転送に失敗しました
他に「スレッド」「ファイルディスクリプタ」「リソース間の依存関係」などが枯渇して二次的に効果が現れる
23章 クリティカルな状態の管理：信頼性のための分散合意
この章が一番この本で難解な部分だった
分散アルゴリズムだとElasticsearchだとZen2やCassandraだとgossipは、知っているが中身や概念を知らないので結構わからない箇所が多かった
今後の課題です
レプリカ数に対する考え 下記を考慮して作成しないといけない
・信頼性に対する要求
・システムに影響する計画済みメンテナンスの類度
・リスク
・パフォーマンス
・コストまた、分散合意を使わずハートビートを使うときは気をつけないとな
26章 データの完全性:What You Read Is What You Wrote
この章は、今で言うとデータエンジニアのために書いた内容であるとも思える
データの完全性のために下記を組み合わせていく
・稼働率
・レイテンシ
・規模
・速度
・プライバシーいわゆる、ACID、やBASE APIなどの特性を持っている
ここで言うBASEは、
BA => 基本的な可用性（Baseically Available）
S => ソフトステート（Soft state）
E => 結果生合成（Eventual Consistency）
ex) BigTableとかはこの性質BASEはACIDよりも可用性を高いめる代わりに分散一貫性の保証が弱まる
結果生合成に関しては下記の資料が分かりやすい
バックアップとアーカイブの違いとは？
アーカイブ： コンプライアンス目的で長期間に渡って安全に保管するデータ
バックアップ： 災害時のリカバリーデータ最後に「おかしくならなものはないというだけでなく、どんなものもいつかはおかしくなる」と言う気持ちも大切にしようと思う
28章 SREの成長を加速する方法：新人からオンコール担当、そしてその先へ
SREってどうやって教育するのかというGoogleのナレッジが書かれている
正直、Googleなんだから素晴らしい人が来るから抽象的なものがくると予想していたが具体的に詳細でとても心理的に優しい感想を持ちました
SREの教育方法
文章として、短くしたが下記のようなことが書かれていた
推奨 ⇆ アンチ
具体的な順序立てられた学習体験 ⇆ 訓練のような下働き作業
リバースエンジニアリング/基本原則 ⇆ 手順通りの作業
ポストモーテム。障害分析 ⇆ 秘密を隠す
障害の事前デモ体験 ⇆ オンコールでの初めての対応
ロールプレイングで試したチーム ⇆ 細分化されたエキスパートチーム
シャドウとしてのオンコール担当 ⇆ 理解する前のオンコール担当
エキスパートとペアを組む ⇆ 分野ごとに異なるエキスパートが教育担当
サービススタックの一部を受け持つ ⇆ 断片的な作業 「過去を思い出せない物は、それを繰り返す運命にある」
まさに、ポストモーテム大切だなと
SRE本で書かれていた「ポストモーテム輪読会」はとても大切だと思います
どこで聞いたか忘れてしまったが新米の戦闘機乗りが、ベテラン戦闘機乗りに今までの経験を聞くだけで死亡率が下がると言う話を聞いたことがあります
サービスレベルによってはやっても良いと思われます（過剰にならないように）
29章 割り込みへの対処
運用負荷に関して書かれています
ここでは、運用負荷＝「道ばたの缶を蹴り飛ばす」「トレル」と呼ばれます
「道ばたの缶を蹴り飛ばす」とは何なのか？
翻訳前のもを確認すると「Kicking the can down the road」と記載があります
どんなに遠くに蹴っ飛ばしてもその問題が消えない → 問題の先送りのことを言います
トイルをなくすためには、下記を目標にします
SRE 1 人あたりの時間を 50% 未満に抑え、残りの 50% をエンジニアリング プロジェクトの作業用に確保することを目標にしています
割り込みへの対処（SLO 重大度 類度 対応できるメンバー）を考え、なるべく削減して集中できる環境を作っていくのが大切だと書かれています
「顧客とともに自分も尊重すること」そうこれがとても大切だなと
感想
SREは、少人数で高品質にビジネスに寄り添った形にしていく物何だなと最後の「34章 まとめ」を読み思いました
この記事が気に入ったらサポートをしてみませんか？