[[SRE NEXT 2024 CFP]]からアウトラインへ落とし込む。 ## 1. はじめに - 10年前自分が新卒のころ - 今の状態：「アドホック」「ツール指向」 - 目の前の問題へ総当たり - サービス開発チームの依頼によるシステム構築、壊れたら直す、バージョンアップ、アドホックな自動化。 - あのツールを導入するとなにか困ったことが解決する。「コンテナ」 - 要素同士の関係性がばらばら - 監視、障害対応、可視化、サーバプロビジョニング、Linux、ハイパーバイザー型仮想化、ロードバランサー、データベース、ストレージ - [[サーバ・インフラを支える技術]] - [[ウェブオペレーション]] - ネットワーク・ルーティング・スイッチング・ ファイアウォール・負荷分散・高可用性・障害復旧・TCPやUDPのサービス・NOC の管理・ハードウェア仕様・複数のUnix環境・複数のウェブサーバ技術・キャッシュ技術・データベース技術・ストレージインフラ・暗号技術・アルゴリズム・傾向分析・キャパシティ計画立案 - 核がないような...? 24/365 - [From Sysadmins to (almost) Flying Unicorns | USENIX](https://www.usenix.org/conference/srecon23emea/presentation/herail) - 2019年SRE考 - 信頼性を制御可能として変更速度を最大化すること。 - 「サービスのユーザー視点でみた信頼性を定義し、信頼性と変更速度を両立させる」 - 技芸から工学へが現実化 - 現在では、SLI/SLOが普及してきた - 過去のSRE NEXTスライド紹介。 - 売上、コストなど、最大化する、最小化することが良いとされる変数は意識されやすいが、ちょうどいい塩梅にする地味な変数が計測され、可視化されるというのはすごい。 - 開発生産性指標 - [[DORA]]、[[SPACE Framework]] - 組織構造[[Team Topologies]] - なにが変わったのか？本来はこうしたかった - (1)今の状態、(2)あるべき/ありたい状態、(3)あるべき状態と今の状態との差分、(4)差分を埋めるために何をすべきか - しかし、システム管理の分野を工学として扱うことの意味は見逃されている。 - 方法論のみに着目すると、アドホックな世界に突入してしまう。 - 大目的は信頼性を制御可能とすること。サブ目的は...。 - 工学的に解ける問題がもっとあるのでは？ - 人間の直感でカバーされている既知の問題 - 分散トレーシング高コスト問題 - アラートストーム問題 - アクションしないアラート問題 - インシデント対応時の各種判断 - その他各種技術の導入の効果測定ができていない問題 - 深淵な問い - シンプルイズベストといいつつ、最近のシステムは複雑になりすぎてないのか？ - とにかく人間の要素を排除して自動化すればいいのか？ - 認知負荷って計測できる？どう下げる？ - 妥当なシステムアーキテクチャはどのように設計されるか？ - 工学としてのSREを再訪する - SREのEはEngineeringであり、Engineeringは工学と訳されるため、「工学としてのSRE」は自明にみえる - エンジニアリング = 工学と認識する習慣はテックコミュニティではない - 「フレームワークを設計する能力が必要なのではないか？」フレームワークのスコープは組織固有であったり、 - フレームワークと理論の違い - 再訪の流れ 1. 工学としてのSREを議論する上で、土台となる背景知識と基本概念を整理する 2. SREに接続される工学分野とその関連論文を紹介する 3. 工学としてのSREのオープンチャレンジを提示する ## 2. システム管理と工学 - 工学への昇華 - 数理的な法則を用いたモデル化が困難である - [[システム工学|システムズエンジニアリング]] - 最近読んだ論文はシステムズエンジニアリングの考え方になっている。 - [[2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]] - [[2023__HotNets__Simplifying Cloud Management with Cloudless Computing|Cloudless Computing]] - システム管理の分野で工学をやる ≠ コンピュータサイエンスの知識を使うこと - [[工学の歴史と技術の倫理]] ## 3. SREに接続される工学・科学分野と論文 - [[SREconでの学術的背景を含むプレゼンテーションリスト]] - 複雑化するシステムの新たな障害パターン - xxx Failure - 複雑さに対する解決は、単純化ではないかもしれない。 - Only complexity can reduce complexity - 「文化」で片付けない。文化をも計測する。 - Measuring Reliability Culture - オペレーターを自動化による排除する発想の限界 - Ironies of Operation - いかにオペレーターの認知負荷を下げるか。 - Process Feeling - 人間同士のコミュニケーション Controlling the Costs of Coordination - レジリエンス工学 [[Resilience engineering papers]] - [[The Morning Paper on Operability]] ## 4. オープンチャレンジ 現代のソフトウェア開発に求められる指針。 - ビジネス要求：高い信頼性を維持しながら仮説検証を高速に繰り返したい。 - 事前に入念に設計するよりもまずはやってみる。 - やってみた体験から得たことを - アプリケーションの機能とそのワークロードが変化する前提では、不確実性が高く、事前に決められることが少ない。そのため、全体俯瞰を要求する工学的アプローチを適用しにくい。 - 変化による不確実性を前提とした組み込んだ工学的アプローチが必要である。 - Chaos Engineering - アジャイル開発 - 一旦リリースしてから経験を得て次を決める。 - Monitoring / Observability - アラーティングの定量的アプローチ - アクションしないアラート問題 - アラートをack後にアクションしたかどうかを記録 - そもそもackすらしていない - 監視条件項目そのものがいらないのでは？と提案できる - テレメトリーのスケーリング - （特にトレーシングは、）収集するデータを細粒度にするほど、ストレージのコストは増大する - 一方でサンプリングすると重要なエラーデータを失う - [[Tracing Sampling Papers]] - Incident Response - インシデント管理の定量的アプローチ - インシデント対応のAIエージェントによる支援 - SLI / SLO - エラーバジェット残量に基づく意思決定の支援 - 原因特定か回復のどちらを優先するか？ - インシデント対応時の事後対応を実施するかしないか？ - キャパシティプランニングの適応的調整 - システムアーキテクチャの導出 - SLOからシステムアーキテクチャを導出する際に、実際は機能やワークロード予想からなんとなくシステムアーキテクチャは決まる(データ指向アプリケーションの設計)。SLI/SLOをなんとなく生成され、システムアーキテクチャに逆フィードバックをかける。冗長度とかにスペックに無駄がある。 - SLOの自動導出もできそう。 - [Introducing the Reliability Map – r9y.dev](https://www.usenix.org/conference/srecon22apac/presentation/bowden) - AI for SRE ## 4. むすび - 本発表の貢献 - 「使う」から「考える」「作る」へ - SREの工学的土台を提示し、根無し草になる不安を解決する - この不確実性の高い世界で、フレームワークを利用するのみであっても、ツール化 - 工学的アプローチそのものを体得する必要があるのではないか？ - 理論を知れば、フレームワークを導出することもできる？