気づけばこうなる運用 ～運用現場の現実と理想～

2025-11-08 関西オープンフォーラム2025
https://www.k-of.jp/2025/

Transcript

1. 気づけばこうなる運用 ～運用現場の現実と理想 ～ id:onk 2025-11-08 関西オープンフォーラム2025 1
2. 2 今日の話
3. 3 気づけばこうなる運用 ～運用現場の現実と理想 ～
4. 4 Webアプリケーション 開発運用課題100連発
5. 自己紹介 • 大仲 能史 a.k.a. id:onk • 株式会社はてな チーフエンジニア • 芸歴20年 ◦ 色んな開発運用の現場を見てきました 5
6. サービス劣化力 世界はサービス劣化力に満ち溢れていて、 サービスを運用していると必ず健康状態が 悪化していきます。 6
7. サービス劣化力の例 • データの蓄積によるレスポンス速度悪化 • 仕様変更による設計の無理 • ライブラリの更新への追随を怠る • 人の流動によるノウハウの低下 • 新法規制への対応 • 突然応答しなくなるサーバ 7
8. 8 現状を維持していると サービスはどんどん 劣化していく
9. 9 デッドコード
10. デッドコード • 「消そう。以上。」 ◦ by Kent Beck (Tidy First? 2章) • とはいえ本当に消していいか 自信を持ちづらい ◦ そもそも見通しのいいコードなら こんなことになってない 10 https://www.oreilly.co.jp/books/9784814400911/
11. okuribito • ruby gems ◦ github shakemurasan/okuribito • 検査対象メソッド名を指定すると 呼び出されたらログを吐く • しばらく監視してから安全に削除 11 https://movies.shochiku.co.jp/100th/okuribito/
12. 12 今日はこんな話を どんどん出します
13. 開発運用課題100連発 • 運用を劣化させる力 • 開発を劣化させる力 • チームを劣化させる力 13
14. 14 運用を劣化させる力
15. 運用を劣化させる力 • サーバは落ちる • サービスも落ちる 15
16. 運用を劣化させる力 • サーバは落ちる • サービスも落ちる 16 • オンプレだと ◦ ディスクが逝く ◦ 電源が逝く ◦ データセンター側で ケーブルを誤抜去
17. 運用を劣化させる力 • ハードに問題が無くても ◦ ディスク容量を食い潰す ◦ inode枯渇 17
18. 18 監視しましょう
19. Mackerelの方から来ました 19 https://ja.mackerel.io/
20. 監視 • リソースの監視 ◦ CPU、メモリ、ディスク、ネットワーク 20
22. 監視 • 通知 ◦ メール通知、Slack通知、PagerDuty、電話、... ◦ 問題があったら通知 • デプロイ後30分ぐらい様子見する生活 ◦ ノールックデプロイに 22
23. 監視トレンドの変化 リソース監視から体験の監視に。 23
24. 監視トレンドの変化 • 仮にCPUが100%に張り付いていたとして、 サービスに問題が出ていないなら良いのでは？ • むしろ効率よくリソースを使えているまである 24
25. 監視トレンドの変化 • R.E.D メソッド ◦ Requests (リクエスト数) ◦ Errors (エラー数) ◦ Duration (実行に掛かった時間。レイテンシー) • 最終的なアプリケーションの挙動を監視する 25
26. • 外形監視 ◦ 外部からHTTPリクエストして、正常応答を確認する • シナリオ監視 ◦ 例えばログインができるかとか、チュートリアルを 終えられるかとか 監視トレンドの変化 26
27. 監視トレンドの変化 • SLI/SLO ◦ Service Level Indicator / Objective ◦ サービスレベル指標 / 目標 • 例えば ◦ 主要パスへのリクエストの99.5%が成功 ◦ 主要パスへのリクエストの99.5%が100ms以内 27
28. 28 SRE
29. • Site Reliability Engineering • SLI/SLOを使って健全性をコントロールする ◦ 現状が健全かどうかの指標がSLI/SLO ◦ SLOを守れている＝どんどん積極開発できる ◦ SLOを守れなかった＝対応が必要 SRE 29
30. SREのプラクティス 30 • Production Readiness Checklist ◦ リリース前に、準備ができているかのチェックを行う ◦ ドキュメントが整備されているか、監視、通知、 障害対応フロー、SLI/SLO、監視ダッシュボード、...
31. 31 要はバランス
32. 要はバランス • 問題発覚前に準備する流れがある ◦ 問題発覚前に準備しなければいけない？ ◦ いつになったらリリースできるのか 32
33. 要はバランス • 問題発覚前に準備する流れがある ◦ 問題発覚前に準備しなければいけない？ ◦ いつになったらリリースできるのか ◦ 達人にでもなるのを待ってから戦場に出るつもりか？ 33
34. 要はバランスというものの • Four Keys ◦ 開発チームのパフォーマンスを示す指標 ◦ デプロイ頻度、変更のリードタイム、変更障害率、 サービス復元時間 • エリートチームは全てで高成績 ◦ バランスではなく、できるところはできている ◦ DevOpsのプラクティスを適用するとやりやすい 34
35. 35 障害対応
36. 障害対応 • 連絡の問題 • 手順や体制の問題 • 原因究明の問題 • 再発防止の問題 36
37. 障害対応：連絡の問題 • 気づくことはできたか • 対応に必要な人を集められたか • 告知の速度や情報が適切だったか 37
38. 障害対応：手順や体制の問題 • 見るべき場所は分かっていたか • 見るべき場所は合っていたか • 最速で問題を直せる役割分担ができたか • 必要な判断を必要なタイミングで下せたか • 対策は打てたのか 38
39. 障害対応：原因究明の問題 • 障害の起因となった原因を見つけられたか • 障害に至った本当の理由を見つけられたか 39
40. 障害対応：再発防止の問題 • 起きないようにすることはできるか • 起きたときに障害時間を最小化できるか • 起きたときに障害対象を最小化できるか 40
41. 障害対応演習 41 シーアンドアール研究所 わかばちゃんと学ぶ サーバー監視 p181
42. 42 オブザーバビリティ
43. オブザーバビリティ 43 https://www.oreilly.co.jp/books/9784814400126/ システムがどのような状態 になったとしても、それが どんなに斬新で奇妙なもの であっても、どれだけ理解 し説明できるかを示す尺度
44. (再掲) 障害対応：原因究明の問題 • 障害の起因となった原因を見つけられたか • 障害に至った本当の理由を見つけられたか 44
45. オブザーバビリティ • 何かが起きていたが原因不明 ◦ 必要なログが出ていない？ ◦ 計装してリリースしなくても、新しい不具合の原因を 突き止められると「オブザーバビリティがある」状態 • 勘や経験による属人化された調査からの脱出 45
46. 要はバランス • 何でも情報を取れば良いってものではない ◦ オブザーバビリティにはお金がかかる • 「情報」は意思決定と行動を促すものである ◦ 意思決定に繋がるように取得する ◦ ノイズが多すぎると生成AIも混乱する 46
47. 開発運用課題100連発 • 運用を劣化させる力 • 開発を劣化させる力 • チームを劣化させる力 47
48. 48 開発を劣化させる力
49. 開発を劣化させる力 • 仕様変更で設計が歪む • ドキュメントとの差異が拡大 • デッドコードを消せていない • ライブラリの更新 • OS・ブラウザが更新される • 旧UIと新UIをずっと併用している 49
50. 50 溜まるIssue
51. 溜まるIssue • 普通に生活をしているだけでチケットは溜 まっていく • 1000 issue超えることもよくある 51
52. 溜まるIssue 52
53. 溜まるIssue • MoSCoWラベルを付けて整理したり ◦ Must, Should, Could, Won't • RICEのような順位付け基準を入れたり ◦ Reach (影響する人数やイベント数) ◦ Impact (どのくらい価値を生むか) ◦ Confidence (その判断に対する自信度合い) ◦ Effort (実装に必要なコスト) 53
54. 意思決定の専任を置くことになる • 閾値 ◦ issueを片付けても減らず、自然増する ◦ issueのタイトルや内容が曖昧なまま放置される ◦ どのタスクを先にやるべきかの議論が増える ◦ 決定事項に対して再説明が必要になる • 認知負荷を全員に押しつけない ◦ 優先度の根拠を共有して、議論コストを下げたい ◦ チームとしての意思を作っていく 54
55. Issueの対応速度は上がっている • AIで倒せるようになってきた ◦ 片手間で直せるものを即座に直せる • 全自動で倒せる環境も整ってきた ◦ CI/CD整備 55
56. Issueの対応速度は上がっている • AIで倒せるようになってきた ◦ 片手間で直せるものを即座に直せる => レビュー疲れ • 全自動で倒せる環境も整ってきた ◦ CI/CD整備 => 整えるのは大変！ 56
57. 57 レビュー疲れ
58. レビュー疲れ • AIによる完成形コード ◦ エラー処理がやたら多いことがよくある ◦ なぜこのエラー処理を入れているのかを読み解けない • 完成形からリバースエンジニアリングは大変 ◦ プロンプトだけを渡してくれ ◦ 要件を言語化する方が専門家は助かる 58
59. 引き算で完成させた最小コード • エラーハンドリングは無視できる ◦ 呼び出し先でエラーにはならない • パフォーマンスは無視できる ◦ 非同期化する必要はない • セキュリティは無視できる ◦ 既に適切にエスケープされている • ... 59
60. 60 CI/CD整備
61. あったらいいに決まってる • テストがあると安心 • 常にデプロイされ続けていると安心 61
62. テストがある方が遅い場合も……？ • 要件が変わったが、テストをどこまで消せば いいかが分からない 62
63. 63 デプロイ今昔
64. デプロイ今昔 • 昔：サーバにrsyncでデプロイ • 今：コンテナをサーバーレスに 64
65. デプロイ今昔 • 昔：サーバにrsyncでデプロイ => 5分 • 今：コンテナをサーバーレスに => 20分 65
66. デプロイ今昔 • サーバのメンテコストから解放される ◦ 責任共有モデル • 上手く使うための 苦労がある？ ◦ build, ship, run ◦ immutable 66 日経XTECH AWSのセキュリティや注意点、「責任共有モデル」を知り使いこなす
67. デプロイ今昔 • トレードオフをどうするか ◦ 要はバランス • 腕力！腕力！腕力！ ◦ buildが最速なら負担にならない ◦ 5分でCI/CDが終わる環境を維持し続ける 67
68. 68 要はバランス
69. 落ちても困らないサービス • 前提：人が死なないサービス • 前提：別のコミュニティで繋がっている ◦ ついったーとかDiscordとか 69
70. 落ちても困らないサービス • 監視 ◦ 基本自分が見ているし ◦ なんかあったらDMくれ • バックアップ ◦ たまたま手元に最新がコピーされてるかも、で十分 ◦ 飛んだら祭りとして楽しむ 70
71. 71 いつしか興味が薄れてい き
72. さすがにこれだと困っちゃう • 監視 ◦ 基本自分が見ているし => 見てない ◦ なんかあったらDMくれ => 気づかない、見ても放置 • バックアップ ◦ たまたま手元に最新がコピーされてるかも、で十分 ▪ => 手元にあるのは数ヶ月前だったり ◦ 飛んだら祭りとして楽しむ => 構築方法も分かんない 72
73. 73 リリース時は興味MAXな ので、全てを事前に自動 化しておく必要はない
74. 74 勤勉な愚者がいなくなる 前に対処できればOK
75. ゼークトの組織論 • 利口で怠慢：指揮官に適している • 利口で勤勉：参謀に適している • 愚鈍で怠慢：命令を忠実に実行するのみの〜 • 愚鈍で勤勉：この者を重用してはならない 75
76. プログラマ三大美徳 • 怠惰：同じことを繰り返したくない • 短気：使いづらいのを見るとイラッとする • 傲慢：自分のコードでなんでも解決できる 76
77. 77 怠惰を発動するタイミン グを選んでいく
78. 自動化するときに考えること 78 毎日起きる 1年に1回起きる 大事なこと 自動化する 手順書、 チェックリスト 些細なこと 発生しないように する 気がつけるよう にする
79. 開発運用課題100連発 • 運用を劣化させる力 • 開発を劣化させる力 • チームを劣化させる力 79
80. 80 チームを劣化させる力
81. チームを劣化させる力 81 • ハネムーンナンバー ◦ 代謝 • 採用、新卒、異動 • 慣れ • 飽き
82. 82 人の異動
83. 人の異動 83 • 異動すると穴が空く • 穴をそのまま埋めるような採用はできない • 形を変えて穴を埋め、新しい形になる ◦ 関係性が変わる
84. 84 認知資源は再分配される
85. 認知資源は再分配される 会話する人が変わる、会話する内容が変わる と、関わり方が変わって、自動化しなくても できていたことはできなくなる 85
86. 優先しない側に落ちると無くなる • 気になったときにチェックしていた ◦ チェック自体が発生しなくなる • ドキュメント差分を無意識に更新していた ◦ 情報が徐々に陳腐化 • 困ってそうな人を自然と見ていた ◦ サポートが偶発的に途切れる 86
87. 87 能力が失われる
88. 能力が失われる • 例えばテックリードの交代 • 今までサラッとできていたことができなくなる ◦ そうならないよう事前にスキトラする ◦ やってみせ 言って聞かせて させてみせ 88
89. テックリードの交代で失われるもの • 違う時間軸で考える力 ◦ 半年後、1年後の予測 ◦ 現状認識と予測から導き出されるギャップ ◦ 開発改善計画 ◦ 事業計画へのインプット 89
90. 90 サバイバルモード
91. サバイバルモード チームに時間的な余裕がなく 「継続的な成長」のための学 習をするゆとりがない状態 91 https://www.oreilly.co.jp/books/9784873118024/
92. 木こりのジレンマ 92 木を切り倒すのに6時間もら えるなら、私は最初の4時間 を斧を研ぐことに費やすだろ う by リンカーン https://ja.wikipedia.org/wiki/エイブラハム・リンカーン
93. ここはサバイバルモード 93 • 斧を研ぐゆとりは無い • サバイバルモードから脱出するまでは 他のことは何もできない
94. ここはサバイバルモード 94 • 歯を食いしばって抜け出す • 整理する • やることを減らす
95. 95 スクラムで作る 頼もしく生き生きとした チーム https://speakerdeck.com/yigarashi/the-lively-trustworthy-team-by-scrum
96. スクラムの三本柱 96 • 透明性：問題を常に可視化する • 検査：プロセスや成果物が適切か確認する • 適応：発見した問題に対処する
97. 97 スクラムイベントがうま くいかない時は大抵前の フェーズがうまくいって いない https://tech.timee.co.jp/entry/2025/06/18/154948
98. 一つ前のフェーズ 98 うまくいかないイベント 改善を試みるイベント プランニング リファインメント、 スプリントレビュー スプリントレビュー スプリントプランニン グ、リファインメント スプリントレトロスペク ティブ プランニング、スプリ ント中の活動そのもの デイリースクラム プランニング
99. 99 チームのバランスを取る
100. 100 プログラマー風林火山 http://blog.livedoor.jp/lalha/archives/50065532.html
101. プログラマー風林火山 • 風：迅速な設計/実装によってチームを加速させる • 林：突発的なトラブルが発生してもチームに乱れぬペースを提供する • 火：新しい技術/方法/ツールの積極的な導入で競争力を生み出す • 山：厳密なエラーチェックと堅牢なプログラミングで安定性を高める 101 http://blog.livedoor.jp/lalha/archives/50065532.html
102. 102 SPACE
103. SPACE • Satisfaction & Well-being（チームの健全性） • Performance（成果・価値） • Activity（活動・実行力） • Communication & Collaboration（協働・連携） • Efficiency & Flow（効率・フロー） 103
104. • Satisfaction & Well-being（チームの健全性） ◦ チームメンバーは現在のプロセス・環境に満足できて いますか？ • Performance（成果・価値） • Activity（活動・実行力） • Communication & Collaboration（協働・連携） • Efficiency & Flow（効率・フロー） SPACE 104
105. • Satisfaction & Well-being（チームの健全性） • Performance（成果・価値） ◦ チーム目標に対して、チームの進捗・達成状況は十分 ですか？ • Activity（活動・実行力） • Communication & Collaboration（協働・連携） • Efficiency & Flow（効率・フロー） SPACE 105
106. • Satisfaction & Well-being（チームの健全性） • Performance（成果・価値） • Activity（活動・実行力） ◦ 目標達成のためのPRマージ・デプロイの数は十分です か？ • Communication & Collaboration（協働・連携） • Efficiency & Flow（効率・フロー） SPACE 106
107. • Satisfaction & Well-being（チームの健全性） • Performance（成果・価値） • Activity（活動・実行力） • Communication & Collaboration（協働・連携） ◦ チーム内のコミュニケーションは十分にスムーズです か？ • Efficiency & Flow（効率・フロー） SPACE 107
108. SPACE • Satisfaction & Well-being（チームの健全性） • Performance（成果・価値） • Activity（活動・実行力） • Communication & Collaboration（協働・連携） • Efficiency & Flow（効率・フロー） ◦ チームメンバーは集中した時間を十分に確保できてい ますか？ 108
109. 開発運用課題100連発 • 運用を劣化させる力 • 開発を劣化させる力 • チームを劣化させる力 109
110. 110 まとめ
111. まとめ • サービス劣化力は無限にある ◦ システムの複雑化 ◦ チーム体制の破壊 ◦ 外的要因の変化 111
112. まとめ • 状況に合わせて要はバランス ◦ リリース速度と基盤メンテコストのトレードオフ ◦ 認知資源と自動化コストのトレードオフ ◦ 木を切るか斧を研ぐかのトレードオフ 112
113. まとめ • コードベースと組織は両輪 ◦ ソフトウェアだけじゃなく、チームも、組織も、 すべてを設計せよ • DevOps ◦ 適正なツールとアジャイルコラボレーションで文化を 変える 113
114. まとめ • それぞれ教科書的な答えはある ◦ 現実を教科書に近づけるのが我々の仕事 • 最後は腕力 114