DevOps・プラットフォーム・SRE エンジニア

コードとしての基盤、配信の流れの定義、構成の記述——何が存在すべきかを述べる、大量の構造のある文章である。

午前三時に、時間に追われ、情報が欠けたまま、何を戻すか、何を落とすか、まだ壊れているあいだ人に何を伝えるかを決める。

クラウドの請求を説明し、それを三倍にした原因を見つけ、そしてどの無駄がエンジニアの一週間をかけて直す価値があるかを決める。

構成を選び、受け入れる壊れ方を選び、そして二年後にもこのチームが運用できるものを選ぶ。

実務者への調査なので、90%は測られた利用ではなく自己申告の利用である。そして併記されている「80%が生産性が上がったと考えている」は信念であり、信念として読まなければならない——このサイトは、経験のある開発者が19%遅くなりながら20%速いと信じていた無作為化試験を持っており、つまり自分の速さについての信念は、速さについての証拠ではない。自分の成績についての自己申告ではないのは、研究者が回答者を横断して計算した相関のほうであり、そしてそれが役に立つ部分である——導入は、処理量と製品の成績とは正の関係にあり、配信の安定性とは負の関係にある。著者が挙げている仕組みは具体的である——強固な自動テスト、成熟した版の管理、速い反応の輪がなければ、変更の量が増えることは不安定さを生む。そして疎に結合された構成のチームは得をし、密に結合されたチームはほとんど、あるいはまったく得をしない。これを公表しているのは Google Cloud であり、そして自ら尋ねている道具を売っている。

ある道具が実際の仕事のために大規模に使われていることが測定されており、しかも使うと決めたのが雇用主ではなく働き手である場合。capability の記録より重い——仕事が実演ではなく本物だからである——そして deployment の記録より軽い。どの雇用主もそれを本番に置いておらず、求めてもおらず、その周りに工程も作っていないからである。重みは `cautious` である——`automating` とは、機械がその業務をできることと、採用の兆しがあることの両方を意味し、これは採用の兆しである——しかし利用は試験的でありうるし、測定の多くは利害のある側から来るので、一件では決して足りず、独立した二件で足りる。誰が数えているかに注意すること。ベンダーの計測データはこれを直に見るが、その道具を売っているので、そうした記録は適用範囲にその利害を明記する。統計機関が企業に「働き手は業務でAIを使っているか」を尋ねる場合、同じ経路を何の利害もなく見ており、それが存在するならそちらが良い出典である。

委託された分野の調査であって測定ではない。ここに記録しているのは、この基盤の大半とは逆の方向を指しているからである。独立した支援のエンジニアリングが縮むと見込んでいるのと同じ文書が、その仕事がこの職に落ちると見込んでいる——DevOps の職能がサービス水準の合意の管理と新しい系の開発を引き取ること、開発と運用が一つになってより総合的な支援を提供すること、そして自動化と統制のエンジニアを需要の伸びる職として挙げていること。また、押し出されると見込まれている支援のエンジニアにとって、容易または中程度の移動先として DevOps エンジニアを名指ししている。そのどれも、誰かが採用された証拠でも、人員が増えた証拠でも、その移行が起きた証拠でもない——一つの機関の見込みであり、生成AIが一般に届く前に公表され、対象はシンガポールのみで、雇用のデータではなく関係者への聞き取りから組まれている。それでも示しているのは、同じ報告書のほかの場所にある「押し出される」という発見が、仕事が消えるという主張ではないということである。

立場のある名指しの人物が、ある日付に、帰属のつく言明として何かを公けに予測した。誰がいつ何を言ったのかが確かめられるまま残るように記録するのであり、そして業務の判断を決して動かさない。予測は観測ではないからである。その価値は後から来る——この記録は、その職業についての証拠と同じページの上に載るので、予測を読む人は、そのあと何が起きたかの記録を隣で読むことになる。それが決算である。この site は、ある予測が当たったかどうかについて何の判定も公表しない。

かつて若手を雇っていた段——設定を書き、つなぐこと——こそ、最もはっきりした仕組みが向けられている段である。成否が機械的に確かめられるコードだからである。そこで初心者に残るのは呼び出し当番であり、それは最も難しく、本来なら稼いでから就くはずの部分である。当番表に載るずっと前から、事案の振り返りに入れてくれと押すこと。

あなたの効き目は設計の判断と事案の一声にあり、そのどちらも一週間のなかの小さな切れ端である。危ういのはそれが自動化されることではなく、その周りの時間が薄くなり、やがて一人のエンジニアが、誰一人頭のなかに保てない数のサービスを覆うことである。ホールスタッフが接客係一人あたりの客数を見るのと同じように、エンジニア一人あたりのサービス数を見ること。

留まって強くする

配線から離れ、設計のほうへ動く

設計の判断には自動の審判がなく、だからこそどの道具もその輪を閉じられない——そしてそれは、この職のなかで積み上がっていく部分である。

職の形を組み替える

他人がつくったものの運用可能性を引き受ける

設定がより多く生成されることは、誰も責任を負っていない系が増えることであり、そして本番で何を動かしてよいかの基準を、誰かが保たなければならない。

設定の半分は動いているし、しかも速い。基盤のコードは、きれいに適用されるかエラーになるかのどちらかだからである——成否が機械的に確かめられることこそ、モデルが監督なしに再試行できるようにする。呼び出し当番は動いていない。事案とは定義からして誰も想定していなかった故障であり、その一声は、正しい答えについてではなく受け入れられる損害についてだからである。ありそうな形は消滅ではなく薄まりである——より少ないエンジニアがより多くのサービスを覆い、それは業務をどれも残したまま当番表を悪くする。

日付は出さない。自分で出せる二つの数字が、どんな予測よりも多くを語る——一週間のどれだけが、適用すれば成功するかエラーになるかのどちらかである仕事に使われているか。そして自分の当番表で、エンジニア一人が何個のサービスに責任を負っているか。一つ目が業務としての晒され具合であり、二つ目が、この職の人に実際に届く変化である。そしてそれは、どの道具が入ってからも二四半期ほど経って静かに動く。

たいていは違う。そしてこれは、節約に見えて負債のように振る舞う道具の、このサイトで最もはっきりした例である。つくられた資源は一つ残らず、誰かが保ち、守り、いずれ消さなければならない資源である。だから設定が速くなることは、仕事を減らすのではなく設定を増やす——そして時間は書くことからほどくことへ移る。ほどくことは計画表の上に映らない。だからこそ、それは節約として予算に計上される。

この職業のなかで最も安全な業務であり、同時に最も小さい業務である。設計が正しかったかは十八か月後に分かる——つまり自動の審判がなく、したがって道具に閉じられる輪もない——が、大半のチームで設計の判断は四半期に数日である。ある職は、最も上級の業務において安全でありながら、時間の大半を失いうる。そしてその隔たりこそ、計画を立てるときに見るべきものである。