Skip to content

Instantly share code, notes, and snippets.

@yuuki
Created August 7, 2024 00:58
Show Gist options
  • Save yuuki/a4464697b0c7585a9fcfb0905f1b6e06 to your computer and use it in GitHub Desktop.
Save yuuki/a4464697b0c7585a9fcfb0905f1b6e06 to your computer and use it in GitHub Desktop.
SRE NEXT 2024プロポーザル

タイトル

  • 工学としてのSRE再訪

発表の概要(500文字以内)

SREが普及するにつれて、システム管理のアプローチは技芸から工学(科学)へ移り変わっています。2010年発行の書籍ウェブオペレーションでは、「ウェブオペレーションは技芸であり、科学ではない。」と書かれています。システム管理の個別具体的な技術はコンピュータサイエンスに依るとしても、個別技術の集合体と人間が統合されたサービスを正常に稼働させ続けることは技芸の範疇にありました。SRE普及以後は、ユーザー視点に基づくエンドツーエンドの信頼性を定義・計測し、計測結果に基づいて、開発・運用の意思決定を行うようになりました。しかしながら、システム管理の分野を技芸から工学へと昇華させるための土台となる知識や過程、その精神は、現在のエンジニアコミュニティにはいまだ共有されていません。

そこで、本発表では、コンピュータサイエンス、ソフトウェア工学、信頼性工学、認知科学などの工学・科学分野がSREにどのように接続されているかを、歴史的な論文や書籍、SREcon、LISAなどのプレゼンテーションを基に、発表者の見解を交えながら、紐解いていきます。

聞いた人が得られるもの(100文字以内)

他の工学分野と比べてシステム管理の分野が工学的土台をもたないことに根無し草のような不安を感じたり、より良い考え方を模索しているエンジニアの方々が、SREが工学的土台をもつことへの理解を得る。

発表の詳細

本発表で予定している内容のアウトラインは次のようになります。

  1. 本発表に対する期待値の合意(3分)

私は今博士論文を書いています。博士論文に書く内容のうち、最古のものはもう8年も前に始めたことも含みます。それを最新の内容まで包含して一つの学術のストーリーとしてまとめ、かつSREを聞いたことがない可能性のある大学の教員の方々に審査されるとなると、エンジニアコミュニティとは異なる視点で「SREをもう一度考える」ことが頻発します。今日の話は、もう一度考えるなかで、生まれたものです。

したがって、本発表の趣旨は、問題解決の事例ではなくSREという分野そのものの、これまでコミュニティでなされてきた理解を聴衆のみなさんと一緒に深めていきたい、ことにあります。SRE NEXTの2020にて発表者が務めた基調講演で、あとから思えばこんな話を本当はしたかったことを、今あらためてやり直すような話です。それはつまり、SRE NEXT 2020をBeyondするような形となるため、SRE NEXT 2024のテーマ「Beyond NEXT」に沿うものであると考えています。

  1. はじめに(7分)

発表者がブログ記事としてまとめた「2019年SRE考」 (https://blog.yuuk.io/entry/2019/thinking-sre) を紹介します。発表者が新卒であった2014年、自分たちが管理するシステムをマクロなレベルで捉えたときに、(1)今の状態、(2)あるべき状態、(3)あるべき状態と今の状態との差分、(4)差分を埋めるために何をすべきか、はほとんど何もわかっていませんでした。そのとき使用していた個別具体的な技術スタックを列挙して、これらに習熟することにより(1)を理解するといった、非常にボトムアップなものの見方をしていました。この記事では、そうしたボトムアップかつ場当たり的に問題に対処する状態を脱した先にある、「サービスのユーザー視点でみた信頼性を定義し、信頼性と変更速度を両立させる」というSREの最たる特徴を紹介しています。

技芸から工学へと5年前に予言したことは徐々に現実になりつつあります。国内のSREコミュニティでは、SLI/SLOフレームワークによるサービスレベルの定量評価とその評価に基づく意思決定が普及しています。技術スタックではなく、信頼性の階層モデルを用いて、Observabilityやインシデント対応能力などのケイパビリティを共通言語とするようになりました。また、「変更速度」をどのように指標化するかについては、書籍「LeanとDevOpsの科学」で提示されたFour Keysやその後登場したSPACEなどのフレームワークの発明により、変更速度より広い意味での生産性を定量評価していく土壌ができつつあります。書籍「チームトポロジー」では、Embeded SREの位置づけがより広い組織開発の知の枠組みで定義されています。

しかし、そもそもシステム管理の分野を工学として扱うとはどういうことなのか?技芸から工学へ昇華するまでに、どのような努力がなされてきたのか、現在のエンジニアコミュニティではほとんど共有されることはありません。そのため、ソフトウェア開発の現場で今なされていることのうち、工学的根拠をもつか、工学として扱える可能性があるかを議論することが難しいでしょう。

そこで、本発表では、工学としてのSREを再訪します。SREのEはEngineeringであり、Engineeringは工学と訳されるため、「工学としてのSRE」は自明である一方で、エンジニアリングと表記したときに、エンジニアコミュニティの慣習ではそれを工学と認識することはほとんどありません。そのため、あえて工学としてSREを再度訪ねるという表現にしています。 再訪の流れは次のようになります。

  • 工学としてのSREを議論する上で、土台となる背景知識と基本概念を整理する
  • SREに接続される工学分野とその関連論文を紹介する
  • 工学としてのSREのオープンチャレンジを提示する
  1. 背景(5分)

2010年発刊の書籍Web Operationsでは、「ウェブオペレーションは技芸であり、科学ではない」と書かれ、SREbookの序文には、1999年の段階で、システム管理はエンジニアリングと呼べるほどの段階には来ていない、と否定されたと[[Mark Burgess]]は述べています。

“Principles of Network and System Administration”[Bur99]の導入部 で、システム管理はヒューマンコンピュータエンジニアリングの形の一つだと私は主張しました。 レビューアの中には「まだそれはエンジニアリングと呼べるほどの段階には来ていない」と強く否定する人もいました。この時点では、私はこの分野は見失われて、独自の魔術師的な文化にとらわれ、進むべき方向が見えなくなっていると感じていました。しかし Google は明確に線を引き、来たるべきシステム管理の姿を現実の存在にしたのです。そして見直された役割が SRE、すなわち Site Reliability Engineerと呼ばれるものでした。 Network and system administration is a branch of engineering that concerns the operational management of human–computer systems. [[Principles of Network and System Administration]]

システム管理だけではありません。アラン・ケイは、2012年のインタビューで[[Computing is pop culture]]と述べ、近代の計算機技術全体がポップカルチャーであると断じています。

ソフトウェア信頼性工学の大家であるMichael R. Lyuによる2007年の論文では、ソフトウェア工学が実際の工学分野に完全に進化していないことと、信頼性が工学分野において最重要要素であると思うと述べています。

「ソフトウェア工学」が真の工学分野として完全には進化していないからである。物理法則や厳密な手順ではなく、人間の判断や主観的な好みが、ソフトウェア工学における多くの意思決定プロセスを支配している。この状況は、ソフトウェアの信頼性工学において特に深刻である。信頼性は、品質を定量的に測定し、その量を適切に設計することができるため、おそらくどの工学分野においても主張すべき最も重要な要素です。しかし、後の節で詳しく述べるように、ソフトウェア信頼性工学はまだその約束を十分に果たしていない。 [[2007__FOSE__Software Reliability Engineering - A Roadmap]]

このように、システム管理やソフトウェア開発では、工学として認められたり、工学へ進化させることに価値を置かれていることがわかります。しかし、日本語で「エンジニアリング」と言ったときに、実務的・技術的な側面に焦点をあてることが多いため、エンジニアリングと訳されたときに、学術的な側面のニュアンスが失われているように思います。

工学であることの要件に、1)一般性:適切な抽象度で対象がモデル化されている、2)客観性: ある設計や手法の良し悪しが適切な指標を用いて定量的・定性的に評価されている、3)既存の工学・知識との接続性、の3点があると考えています。

SREconでは、コンピュータサイエンス、レジリエンス工学、認知工学の知識をSREに適用する発表は珍しくない上に、登壇者はPh.D取得者であるケースも少なくありません。

Mark Burgessがシステム管理の分野はヒューマンコンピュータエンジニアリングの一部であると述べていることから、SREは計算機のみならず人間の側面を含みます。そのため、テクノロジー以外の学術分野とも接続されます。

計算機に閉じた信頼性か人間の要因も含めた信頼性であるかの議論を整理するために、発表者独自の信頼性オニオンモデルを導入します。このモデルでは、コンポーネントレベル、システムレベル、サービスレベルと順により広範囲の信頼性を取り扱う。最上位層では、人間による手動制御を必要とします。

  1. SREに接続される工学・科学分野と論文(20分)

SREに接続される工学・科学分野について、論文を主体として、SREとどのように関係するかを分野ごとに紹介していきます。(現時点で完全なリストができておらず、その他、レジリエンス工学などの文献を紹介予定)

運用を扱うコンピュータサイエンス:

2000年代から大規模ウェブアプリケーションの運用に関わる論文は多数あります。

  • Adrian ColyerによるThe Morning Paper on Operabilityを紹介する。
    • 運用性に着目したコンピュータサイエンス論文は少ないと思っていたが意外と多い。
  • [[2003__USENIX Symposium__Why do Internet services fail, and what can be done about it?]]
  • [[2007__LISA__On designing and deploying internet-scale services]]
    • 信頼性はシステムの設計フェーズに組み込む必要がある
  • [[2017__HotOS__Thinking about Availability in Large Service Infrastructures]]
  • [[2017__HotOS__Gray Failure - The Achilles Heel of Cloud Scale Systems|Gray Failure]]、[[2021__HotOS__Metastable Failures in Distributed Systems|Metastable]] Failureなど、障害パターンを分類している。

信頼性工学:

SREは、オンラインで頻繁に変更される一点ものの「サービス」ではなく、一度開発が完了すると顧客へ複製が出荷されるソフトウェアにスコープがあることがわかります。

  • 信頼性工学
    • SREBookでの信頼性の定義は信頼性工学に由来する。
    • [[2006__Reliability Engineering and System Safety__Highlights from the Early (and pre-) History of Reliability Engineering]]
  • ソフトウェア信頼性工学
    • [[2019__arXiv__The First 50 Years of Software Reliability Engineering - A History of SRE with First Person Accounts]]
    • [[2013__JCSS__A Survey on Reliability in Distributed Systems]]

ソフトウェア工学:

  • [[継続的デリバリーのソフトウェア工学]]
  • DevOps
    • [[LeanとDevOpsの科学|Accelerate]]
    • [[2019__ACM Computing Surveys__A Survey of DevOps Concepts and Challenges]]

認知科学:

  • [[Ironies of Automation]]
  • [[How Complex Systems Fail]]
  1. SREのオープンチャレンジとむすび(5分)

工学的見地にたった、SREのオープンチャレンジを提示します。

  • インシデント対応のソフトウェアによる定式化と自動化
  • 可制御性の実現:可観測性から、観測結果をシステムへ人間のオペレーターを介さずに直接フィードバック可能な可制御性を実現すること。[[Human in the Loop]]による半自動化。
  • システムの振る舞いのモデル化
    • 分散コンピューティングシステムの振る舞いを形式的なモデルへ帰着することの困難性
  • AIによる個別化の世界。
    • 将来的には、ユーザーが(意思決定のみを行う)システム管理者になるのではないか?
    • TCPの輻輳制御のように、限られたリソースの分配問題が浮上するかもしれない
    • 計算社会科学のアプローチが必要となってくるかもしれない。

ともすれば工学は、厳格なプロセスを意図せず強制しかねないため、自由さを失っていくことにもつながりかねません。この世界が工学化していくことを純粋に喜んでいいのかはまだわかりません。将来、AIを通じた運用が普及し始めると、オペレーターの理解を超えたものをうまく扱うための技芸が進歩する可能性もありますが、それはまた別の話になります。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment