🌟
ゆるSRE勉強会 #7 ~1周年記念企画真夏のSRE怖い話~ に参加なぅ

2024/08/30に公開
今日は「ゆるSRE勉強会 #7 ~1周年記念企画 真夏のSRE怖い話~」に来ています。

普段は DBRE をやってるんですがそろそろ SRE の方々ともコラボしながら色々楽しいことしたいなぁと思っているのでとても楽しみです！
ハッシュタグ ：#yurusre

 19:25-19:30	会場スポンサー LT登壇者: Findy DevRel 岡田さん
Findy のビジョン
挑戦するエンジニアのプラットフォームを作る

Findy のサービス
マッチングサービス
組織分析 SaaS
開発ツールメディア

エンジニア向けレポートも半期に一度やっている
SRE に関するアンケートをやっている
https://jp.surveymonkey.com/r/9T5CMXZ



 19:30-19:40	『ある日突然DBの性能が1/2になった話』登壇者: hmatsu47(まつ)さん
名古屋で Web インフラお守り係
今日も順調に新幹線止まっている

仕事に関係なく pgvector の周辺を追っかけている
本業は MySQL

それは真冬に起きたこと
2018年正月。。。
前年の某社
オンプレ運用
壊れるストレージ
冗長化電源が両系同時故障

繋がらない修理窓口
専属担当者付きプレミアムサポートのはずなのに。。。

終わらない修理立ち会い
保守部品への交換完了 → 動作確認 → 保守部品不良発覚 → 再修理
金曜夜に故障 → 土日を潰す



秋になり
なんとか AWS への Lift & Shift が完了
DB は MySQL → Aurora MySQL へ
若干不安定
アクセスが多い時フェイルオーバーすると DB 接続が刺さる
オンプレ日でネットワーク霊天使が大きくなったため




有効な解決策がないまま年末年始
AWS コンピュート基盤性能低下
2/3 くらいの性能に。。。

祈りながら Datadog のメトリクスグラフを眺め続けることに
いざとなったらスケールアップできるよう手配
稟議を通す
ついでに新しいインスタンスタイプへの変更を準備


数日後。。。
いきなり性能が元通りに

結果スケールアップは不要に
新しいインスタンスタイプへの変更はやった

その後 DB 接続の改善を実施
フェイルオーバーが怖くなくなった


ある日の偉い人
AWS だけでは不安だ、マルチクラウド化を進めてくれ
当時同等の性能を持つクラウドはなかったｗ




 19:40-19:50	『DynamoDBのcapacityを1にしてしまった話』登壇者: @hisamouna34(ささもと)さん
エウレカの SRE & Data Platform の方
前提
Dynamo DB のキャパシティモード
オンデマンドキャパシティモード
プロビジョンドキャパシティモード


ペアーズでは2つのモードを併用
オンデマンドモード
予測不可能なワークロード
低トラフィックなテーブルのための管理のしやすさ優先

プロビジョンドモード

メンテナンス作業時に起こりうる問題
メンテナンスインによりトラフィックがなくなる
メンテナンスアウトによりユーザーリクエスト発生
捌ききれなくなる


検討した対策
プロビジョンドモードの最小キャパシティ値を最大キャパシティ値と同値にする
プロビジョンドモードテーブルを一時的にオンデマンドモードに変更 (こっちを採用)

後日プロビジョンドモードへ変更
キャパシティが 1で適用された
ユーザーリクエスト来ていたので捌けなくなった

terraform の ignore_changes 設定
capacity を ignore_change すると capacity が 1になる？
terraform provider の仕様を疑う
ignore_change 設定しないのはダメなのか？
plan でドリフトが出続けちゃう
terreform apply するたびにキャパシティが戻ってしまう

ignore_change をコメントアウト、戻すを毎回やって対応
自動化と CI で多段防御




 19:50-20:00	『知らないサーバ』登壇者: @ryuichi_1208 さん
甚爾のバックグランド
とある Webサービスのインフラエンジニア
ジョインした時点でインフラの前任者は退職済み
プライベートクラウド上の VM の運用者
100近い VM を ansible で管理

とある日
サーバいっぱいあって楽しい
新しいプラットフォームを作ったので移設してください！

移設
新プラットフォームへのマイグレーション作業が派生
1年くらいかけて完了

１週間後くらい
古いところで動いているサーバがあった
聞いたことも見たこともないサーバ
管理者は退職済みの人

調べてみると
Ansible のサーバ一覧にはなかった
Github を検索しても出てこない
ssh はできた
uptime は 2000日

誰も使ってないだろう、消そう
/var/log 以下にたくさんリクエストが来ていた
ユーザーっぽいリクエストがある
誰にも知られずに使われていた

何に使われているかわからないのでアプリケーションを読む
ps コマンドで lsof でアプリケーションのソースを特定
管理画面も存在することがわかった

誰が使っているかを調べる
Slack で聞いても誰も知らない
リクエストの IP からチームを特定

移設が決定
構築方法が不明
CentOS5 で EOL 済み
何が入ってるかわからない


整備
apache 1 系がそのままだとビルドできないが CentOS 7 に移行
旧プラットフォームのマネージド Gearman が必要だった


学び
IaC は偉大
スクリプト言語で書かれていたのが幸運だった
手動構築で速いのはその時だけ

あなたのネットワークにも知らないサーバいるかもしれませんよ


 20:10-21:00	パネルディスカッション『障害が起きたらどう動く？ 今日からできるインシデントレスポンス』登壇者: **@soudai1025 さん、@fujiwara さん、@integrated1453 さん、@jacopen さん**
**@jacopen さん**
PagerDuty
現役で SRE をやっているわけではない
プロダクトエバンジェリスト
プラットフォームに関わっていた
Hasicorp だったり VMWare だったり
月数回は障害対応に関わる

**@fujiwara さん**
カヤックの SRE
エンジニア歴25年、枕元に携帯を置いて25年
最近は潰し切ったのでオンコールとかの数は落ち着いてきた
もともとバックエンドエンジニア
何かあったらコード読んで原因特定をしている


**@integrated1453 さん**
NewsPicks の SRE
PagerDuty なったらサクッと4 番押すくらいには慣れてるｗ
SRE も開発チームも関係なく障害対応は全員がやる

今までで一番震えたインシデントは？

**@integrated1453 さん**
自分がやっちゃった系
オンコール対応しててサーバがハングしてしまうことはまぁまぁあった
ちょっとこなれてきた頃
サーバを物理的にオンオフするということをリモートからやった
知らないサーバを落としてしまった

慣れた時が一番危ない


**@fujiwara さん**
ソシャゲやってた時
オンプレで VM
エンジニアが MySQL に対してデータリセットしちゃった

すぐメンテに入れて、朝のデータを Restoreからの binlog 充てた
復旧できた！




**@jacopen さん**
2012年の閏秒
あちこちの Linux が落ちた
２桁台

全台とりあえず再起動で対応


好きな障害は？

**@soudai1025 さん**
パフォーマンスチューニングが好き
ゴールがちゃんとあるので好き



**@jacopen さん**
物理のネットワークだったらわかるけどオーバーレイのネットワークはわかりづらい
仮説立てながら解決していくしかない
仮想ネットワークのバグだった
20時間くらいかかったけどたどり着いたことが達成感があった

仮想ネットワークの製品は一般企業採用すべきではないｗ



**@fujiwara さん**
嫌いな障害は前に見たことがあるやつ
2回3回来ると2度と見たくない

初めてみるのはやりがいがある
よく見る障害は障害になってない障害
サーバが一台落ちているとか



**@integrated1453 さん**
初見の障害好き
新しい機能リリースした時にパフォーマンス問題が出た時とかありがたいと思う
エンジニアの予想以上にサービスを使ってくれているってことで


嫌いな障害は？

**@jacopen さん**
自己嫌悪になるようなこと
初歩的なところでやらかしたってなると結構やだ


ポストモーテムって障害からどれくらい経過したらやりますか？ポストモーテムをやるタイミングじゃない時ってどんな時ですか？

**@integrated1453 さん**
インシデント対応の中で暫定復旧までは行って初回撲滅をやった上で翌営業日までにはポストモーテムを実施
できれば当日やる
再発防止をできる人が集まればそれで実施
鉄は熱いうちに打て



**@fujiwara さん**
ユーザー影響があったものだったり SLO に影響を与えたものはやるようにしている
なるべく数日中に実施
最初は翌営業日までに書いて全部でも１週間でやる

月刊ポストモーテムを Slack に流している


**@jacopen さん**
インシデント終息宣言が出たらすぐにやる
WarRoom が閉じられる瞬間にはポストモーテムもセット


インシデントを起こしてしまったメンバーへのフォローで大切にしていることはなんですか？

**@fujiwara さん**
基本的に Review を通っているのでチームの責任であって人に向けない


**@jacopen さん**
人的ミスと書くな、と書いてあった
本当の意味の人的ミスはほとんどない
コマンド間違えたとかだったとしても例えばスクリプトにしておけばよかったとか突き詰めた時にその裏側に何があるか、を考える
人間にやらせていること自体が障害を発生する可能性を増やす



**@integrated1453 さん**
根本対応でプロダクト自体の伸び代と考える
チームの責任であることを前提として改善リードするチャンス来たんじゃない、という感じだったり
DB のマイグレーションを CICD で実施
ALTER TABLE でロック
オンラインでできるものとそうじゃないもののポリシーが整備されていない状態



**@soudai1025 さん**
ピンチはチャンス
葬式モードは良くない
ポジティブに向き合う


待機手当は出していますか？障害対応をどう評価している？

**@soudai1025 さん**
リンケージは出ていない
障害対応を再発防止した人を評価する


**@jacopen さん**
適切に休ませるということは絶対やったほうがいい
インシデント中にアドレナリン出ちゃうと仕事できちゃう
無理矢理にでも休ませる
会社でホテルとか食事とか手配して、みたいなのを強くお勧めしている



**@fujiwara さん**
手当はない、ベストエフォート
評価システムが独特で上司が評価するのと 360度評価だと 360の方がウェイトが高い
普段お世話になっている人の方が上に上げたくなったりする
障害対応とかでも対応するオーナーシップを持たせることができる

金曜デプロイはやめよう
金曜にデプロイさせようとしたプロデューサーとかがいたら土日出勤して代休の調整までさせた



**@integrated1453 さん**
待機手当はない
プライマリーオンコールでシフトが回っていく
セカンダリに鉄壁の管理職が控えている
業務時間中に取るのは責務、だけど業務時間外だったら加点評価になっていたりしている


インシデントレスポンスを改善していく活動において、苦労した点、難易度が高いと感じたものを教えてください。

**@soudai1025 さん**
RunBook書くといいよ


**@jacopen さん**
体系的な対応していくのに苦戦しているイメージ
インシデントコマンダーをどうやって育成していくか
意思決定ができる
厳格さを持って対応できる
その時は CEO よりも権限が強くなる




**@fujiwara さん**
チームとして対応できない時、人数がいないとか
経験の浅い人が動けない
ダッシュボードだったりログだったりを標準的に整備
普段から見ておく
平常時を知らないと異常に気付けない





**@integrated1453 さん**
インシデントマネジメントの観点から
障害が発生 → 検知 → アサイン → 復旧 のステップがある
検知するまでを短くする
アサインされるまでを短くする
この二つはトレーニングできる




インシデント対応、どうやって後輩育成している？

**@integrated1453 さん**
なるべくいろんな人に障害対応してほしいと思っている
インシデントコマンダー育成中
ジュニアなメンバーをアサインしてみたり




**@fujiwara さん**
経験の浅いメンバーは見る方に回ってしまうので思考の方向性をチャットに書いてどうやって実行しているかを伝えるようにしている


**@jacopen さん**
思考の過程をチャットに書くのはめちゃくちゃいいと思う
GenAI の時代になってきたのでうまく整理していい感じにできる地盤ができつつある
属人性排除という点では遺ンシデントコマンダーがいたとして、誰ができるか？という風な聞き方をしてはいけない
できる人しかやらない
その他が傍観者になってしまう
ちゃんとアサインする
ゆるSRE勉強会 #7 ~1周年記念企画真夏のSRE怖い話~ に参加なぅ

19:25-19:30 会場スポンサー LT

19:30-19:40 『ある日突然DBの性能が1/2になった話』

19:40-19:50 『DynamoDBのcapacityを1にしてしまった話』

19:50-20:00 『知らないサーバ』

20:10-21:00 パネルディスカッション『障害が起きたらどう動く？今日からできるインシデントレスポンス』

Discussion

19:25-19:30 会場スポンサー LT

19:30-19:40 『ある日突然DBの性能が1/2になった話』

19:40-19:50 『DynamoDBのcapacityを1にしてしまった話』

19:50-20:00 『知らないサーバ』

20:10-21:00 パネルディスカッション『障害が起きたらどう動く？ 今日からできるインシデントレスポンス』

Discussion

20:10-21:00 パネルディスカッション『障害が起きたらどう動く？今日からできるインシデントレスポンス』
