コスト削減から本当に効率化へ - 虎嗅網#
#Omnivore
ハイライト#
複雑さはコストの一種であり、したがってシステムを構築する際の重要な目標はシンプルさであるべきです。 ⤴️ ^571189de
「知的パワー」はもう一つの重要な問題です。知的パワーは空間的に累積するのが難しいです —— チームの知的パワーはしばしば最も経験豊富な数人のキーパーソンのレベルと彼らのコミュニケーションコストに依存します。例えば、データベースに問題が発生した場合、データベースの専門家が必要です；Kubernetes に問題が発生した場合、K8S の専門家が必要です；
しかし、データベースを Kubernetes に置くと、個別のデータベース専門家と K8S 専門家の知的帯域幅は重なりにくいです —— 問題を解決するにはダブルエキスパートが必要です。認証サービスとオブジェクトストレージの循環依存も同様です —— 両方に精通したエンジニアが必要です。二人の独立した専門家を使うことは可能ですが、彼らの間の協調効果は平方的に増加するコミュニケーションコストによって負の利益に引き下げられやすく、故障時に人が多いと愚かになるのはこの理屈です。 ⤴️ ^8a2f1e42
しかし、組織の暗黙の知識はベテランが去ることで失われ、一定の程度まで失われると、このシステムはすでに死に体になっています —— ただ一つのきっかけで崩壊するだけです。 ⤴️ ^1ec94f76
** 第三のポイントは管理理念と洞察力です。** 例えば、安定性の構築には 1000 万の投資が必要ですが、常に機会主義的な草野球チームが現れて「500 万またはそれ以下で済む」と言うでしょう —— そして何もせず、問題が発生しないことを賭け、勝てば得をし、負ければ去るのです。しかし、このチームが本当に技術でコストを削減する能力を持っている可能性もありますが、リーダーシップのポジションにいる人々の中でその点を本当に見分けられるだけの洞察力を持っている人はどれだけいるでしょうか？ ⤴️ ^d92fc421
これは、狼と香辛料の中の商人が言った「何が売れるか」というのは実際には無責任な発言ですが、当たれば分け前がもらえ、外れればコストはかからないということです。
安全感がない問題 ⤴️ ^b97b5eb8
孟子は言いました：「君が臣を手足のように見れば、臣は君を腹心のように見る；君が臣を犬馬のように見れば、臣は君を国人のように見る；君が臣を土芥のように見れば、臣は君を敵のように見る。」 ⤴️ ^9aad170b
コスト削減から本当に効率化へ#
この記事では、インターネット大手企業のコスト削減と効率化の問題について議論し、コスト削減から笑いを取る現象を指摘しています。著者は、コスト削減と効率化にはシステムの複雑さコストを削減し、管理の効率を高める必要があると考えています。しかし、多くの企業はこの 2 つの側面でうまくいっておらず、サービスの故障が頻繁に発生しています。この記事は、インターネットプラットフォームに対する効果的な規制を呼びかけ、本当のコスト削減と効率化の重要性を提起しています。
・💡 コスト削減と効率化にはシステムの複雑さコストを削減し、管理の効率を高める必要があります
・💡 複雑さコストはシステムを構築する際に考慮すべき重要な目標です
・💡 管理レベルと理念の低さはコスト削減と効率化の失敗の原因の一つです
年末はパフォーマンスを上げる時期ですが、インターネット大手企業では大事故が続発しています。コスト削減と効率化を「コスト削減と笑い」にしてしまいました —— これはもはや単なるジョークではなく、公式の自嘲から来ています。
双 11 が終わると、アリババクラウドは業界記録を破るグローバルな大失敗を引き起こし、11 月には連続爆発モードに入り、小さな故障の後、再び 2 時間の国際的なクラウドデータベース管理の大故障が発生しました —— 月次爆発から週次爆発、そして日次爆発へと進みました。
しかし、言葉が終わらないうちに、滴滴は 12 時間を超える大失効が発生し、数億の資損が出ました —— 代替品であるアリババ傘下の高德打车は直接爆発的な注文を受け、利益を得ました。
私はすでに死んだふりをしているアリババクラウドの復盤を行いました《私たちはアリババクラウドの大失敗から何を学べるか》：Auth が設定ミスでダウンし、根本原因は OSS/Auth の循環依存であり、ブラックリストとホワイトリストを変更するとデッドロックが発生しました。
滴滴の問題は、Kubernetes のアップグレードの大失敗だと言われています。この驚くべき復旧時間は通常、ストレージ / データベースに関連しており、合理的に推測される根本原因は：K8S マスターを不注意にダウングレードし、複数のバージョンを一気に飛ばしたことです —— それによって etcd のメタデータが汚染され、最終的にすべてのノードがダウンし、迅速にロールバックできなくなりました。
故障は避けられないものであり、ハードウェアの欠陥、ソフトウェアのバグ、または人的操作ミスによって発生する確率はゼロにはなりません。しかし、信頼性のあるシステムはフォールトトレランスの弾力性を持つべきです —— これらの故障を予測し、対処し、影響を最小限に抑え、全体の失効時間をできるだけ短縮することが求められます。
残念ながら、この点において、これらのインターネット大手企業のパフォーマンスは水準を大きく下回っています —— 少なくとも実際のパフォーマンスは彼らが主張する「1 分で発見、5 分で処理、10 分で復旧」とは大きく異なります。
コスト削減と笑い
** ハイン法則によれば、一つの重大な故障の背後には 29 回の事故、300 回の未遂事故、数千の事故の危険因子があります。** 民間航空業界でこのようなことが発生した場合 —— 実際に何らかの結果を引き起こす事故が発生する必要はなく、単に 2 件の事故の兆候が連続して発生するだけで —— それすら事故ではない場合でも、恐ろしいほど厳しい業界の安全整備がすぐに全面的に展開されるでしょう。
信頼性は重要です。空中交通管制や飛行制御システムのような重要なサービスだけでなく、私たちはより多くの平凡なサービスやアプリケーションが信頼性を持って運営されることを期待しています —— クラウドプロバイダーの全体的な不可用故障はほぼ停電と同等です、移動プラットフォームのダウンは交通運力ネットワークの一部が麻痺することを意味し、電子商取引プラットフォームや支払いツールの不可用は収入と評判に大きな損失をもたらします。
インターネットは私たちの生活のあらゆる側面に深く浸透していますが、インターネットプラットフォームに対する効果的な規制はまだ確立されていません。業界のリーダーは危機に直面したときに死んだふりを選び —— 誰も率直な危機管理や故障の復盤を行おうとしません。誰も答えません：これらの故障はなぜ発生したのか？それらは今後も発生するのか？他のインターネットプラットフォームはこれに対して自己点検を行ったのか？彼らは自分たちのバックアッププランが依然として有効であることを確認したのか？
これらの質問の答えはわかりません。しかし、無制限に複雑さを積み重ね、大規模なリストラの悪影響が現れ始めていることは確かです。サービスの故障はますます頻繁に発生し、新たな常態となるでしょう —— 誰もがいつでも次の笑い者になる可能性があります。この暗い未来から脱却するために必要なのは、本当の「コスト削減と効率化」です。
コスト削減と効率化
故障が発生すると、問題の認識 — 分析 — 解決のプロセスを経ます。これらすべての作業にはシステムの開発 / 運用スタッフが頭を使って取り組む必要があり、その過程で基本的な経験則があります：
故障処理にかかる時間 t = システムと問題の複雑さ W / オンラインで利用可能な知的パワー P
故障処理の最適化の目標は、故障回復時間 t をできるだけ短縮することです。例えば、アリババがよく話す「1-5-10」の安定性指標：1 分で発見、5 分で処理、10 分で復旧は、時間のハード指標を設定しています。
時間制限が厳しい場合、コストを削減するか、効率を高めるかのどちらかです。ただし、** コスト削減は人件費ではなく、システムの複雑さコストを削減することです；効率を高めることは報告のための話題や笑いを増やすことではなく、オンラインで利用可能な知的パワーと管理の有効性を高めることです。** 残念ながら、多くの企業はこの 2 つのことをうまく行っておらず、コスト削減と効率化を「コスト削減と笑い」にしてしまっています。
複雑さコストの削減
** 複雑さにはさまざまな別名があります —— 技術的負債、クソコード、泥沼、アーキテクチャのジャグリング体操。** 症状は、状態空間の急増、モジュール間の密接な結合、複雑な依存関係、一貫性のない命名と用語、パフォーマンス問題を解決するためのハック、回避すべき特例などとして現れることがあります。
== 複雑さはコストの一種であり、したがってシンプルさはシステムを構築する際の重要な目標であるべきです。== しかし、多くの技術チームは提案を策定する際にこれを考慮せず、むしろどう複雑にするかを考えます：数個のサービスで解決できるタスクを、無理にマイクロサービスの理念で数十個のサービスに分割する；あまり機械がないのに、Kubernetes を使って弾力性のあるジャグリングをする；単一のリレーショナルデータベースで解決できるタスクを、無理に数種類の異なるコンポーネントに分けたり、分散データベースを使ったりします。
これらの行動は大量の追加の複雑さを引き起こします —— 具体的な実装から生じるものであり、問題自体に固有の複雑さではありません。最も典型的な例は、多くの企業が必要かどうかにかかわらず、何でも K8S に押し込むことを好むことです。etcd / Prometheus / CMDB / データベース、問題が発生すると循環依存で大失敗し、一度大きな故障が発生すると完全に復旧できなくなります。
また、複雑さコストを支払うべき場所で、多くの企業は支払いたがりません：一つのデータセンターに特大の K8S を置くのではなく、複数の小さなクラスターでグレースケール検証、ブルーグリーンデプロイメント、ローリングアップグレードを行うべきです。バージョンごとの互換性のアップグレードが面倒だと感じ、複数のバージョンを一度に飛ばそうとします。
歪んだエンジニア文化の中で、多くのエンジニアは無駄に大きな規模や高所でのジャグリングを誇りに思います —— そしてこれらの苦労して作り出した技術的負債は、故障時に業報として返ってきます。
==「知的パワー」はもう一つの重要な問題です。知的パワーは空間的に累積するのが難しいです —— チームの知的パワーはしばしば最も経験豊富な数人のキーパーソンのレベルと彼らのコミュニケーションコストに依存します。例えば、データベースに問題が発生した場合、データベースの専門家が必要です；Kubernetes に問題が発生した場合、K8S の専門家が必要です；==
== しかし、データベースを Kubernetes に置くと、個別のデータベース専門家と K8S 専門家の知的帯域幅は重なりにくいです —— 問題を解決するにはダブルエキスパートが必要です。認証サービスとオブジェクトストレージの循環依存も同様です —— 両方に精通したエンジニアが必要です。==
システムの複雑さコストがチームの知的パワーを超えると、翻車的な災害が発生しやすくなります。しかし、これは普段は見えにくいです：なぜなら、問題のあるサービスをデバッグして分析し解決する複雑さは、サービスを起動して運営する複雑さをはるかに上回るからです。普段はここで 2 人を削減し、あそこでも 3 人を削減しても、システムは正常に動作しているように見えます。
== しかし、組織の暗黙の知識はベテランが去ることで失われ、一定の程度まで失われると、このシステムはすでに死に体になっています —— ただ一つのきっかけで崩壊するだけです。== 廃墟の中で、新しい世代の若いエンジニアが徐々にベテランになり、すぐにコストパフォーマンスを失って解雇され、上記のサイクルの中で繰り返されます。
管理の効率を高める
アリババクラウドや滴滴は十分に優秀なエンジニアを雇えないのでしょうか？そうではなく、彼らの管理レベルと理念が低いため、これらのエンジニアをうまく活用できていません。私はアリババで働いたことがあり、探探のような北欧スタイルのスタートアップやアップルのような外資系企業で過ごした経験があり、その管理レベルの差を深く実感しています。いくつかの簡単な例を挙げることができます：
** 第一のポイントはオンコールです。** アップルでは、私たちのチームは 3 つのタイムゾーンに分かれた十数人で構成されています：ヨーロッパのベルリン、中国の上海、アメリカのカリフォルニア、作業時間は首尾よく接続されています。各地のエンジニアはさまざまな問題を完全に処理するための知的パワーを持ち、常に勤務時間中にオンコール待機する能力を保証し、同時に各自の生活の質にも影響を与えません。
しかしアリババでは、オンコールは通常開発者が兼任する責任になり、24 時間いつでもサプライズがある可能性があります。夜中にアラートが鳴り響くことも珍しくありません。実際に人やリソースを使って問題を解決できる場所では、逆にケチになります：開発者が眠そうに起きてコンピュータを開き VPN に接続するまでに、すでに数分が経過しているかもしれません。
** 第二のポイントはシステム構築です。** 例えば、故障処理の報告を見ると、コアインフラサービスの変更がテストされず、監視もアラートも検証もグレースケールもロールバックもなく、アーキテクチャの循環依存が考慮されていない場合、確かに草野球チームの称号に値します。具体的な例を挙げると、監視システムです。良好に設計された監視システムは故障の判定時間を大幅に短縮できます —— これは本質的にサーバーの指標 / ログを事前にデータ分析したものであり、この部分は直感、インスピレーション、洞察力が最も必要で、最も時間を要するステップです。
根本原因を特定できないことは、可観測性の構築と故障対策が不十分であることを示しています。データベースの例を挙げると、私が PostgreSQL の DBA をしていたときに作成した監視システムは、左の図のように、数十のダッシュボードが密接に組織されており、PG の故障が発生した場合、マウスで数回クリックするだけで 1 分もかからずにさまざまな問題を特定し、迅速に計画に従って処理して復旧できます。
次に、アリババクラウドの RDS for PostgreSQL と PolarDB クラウドデータベースの監視システムを見てみると、すべてのものがこの可哀想な一ページの図だけで、彼らがこのもので故障を分析し特定しようとしたら、他の人が数十分かかるのも無理はありません。
== 第三のポイントは管理理念と洞察力です。==== 例えば、安定性の構築には 1000 万の投資が必要ですが、常に機会主義的な草野球チームが現れて「500 万またはそれ以下で済む」と言うでしょう —— そして何もせず、問題が発生しないことを賭け、勝てば得をし、負ければ去るのです。しかし、このチームが本当に技術でコストを削減する能力を持っている可能性もありますが、リーダーシップのポジションにいる人々の中でその点を本当に見分けられるだけの洞察力を持っている人はどれだけいるでしょうか？==
さらに、高度な故障経験はエンジニアや企業にとって非常に貴重な財産です —— これは真金で得た教訓です。しかし、多くの管理者は問題が発生したときに最初に考えるのは「プログラマー / 運用を犠牲にする」ことであり、この財産を次の会社に無駄に送ってしまいます。このような環境では、自然に責任転嫁文化や、何もしないこと、安易に過ごす現象が生まれます。
** 第四のポイントは人を中心にすることです。** 私自身の例を挙げると、私は探探で自分の DBA としてのデータベース管理業務をほぼ全自動化しました。私がこのことをする理由は：まず、私自身が技術の進歩から得られる利益を享受できるからです —— 自分の仕事を自動化すれば、たくさんの時間を持ってお茶を飲んだり新聞を読んだりできます；会社も私が自動化して毎日お茶を飲んで新聞を読んでいるからといって私を解雇することはないので、== 安全感の問題 == がなく、自由に探求でき、一人で一整套の完全なオープンソース RDS を作り出すことができます。
しかし、このようなことがアリババのような環境で起こるでしょうか？「今日の最高のパフォーマンスは明日の最低の要求です」、いいえ、自動化を行ったのですね？結果として、勤務時間が不足していると、管理者はあなたに無駄な仕事や無駄な会議を埋めるように求めます；さらに悪いことに、あなたが一生懸命にシステムを構築し、自分の不可欠性を打ち消した場合、すぐに狡猾な人があなたの成果を奪う結果になります。最終的なゲーム理論の戦略は、外に出て独立して働くことができるか、装って列車に乗って揺れながら前進しているふりをすることです。
最も恐ろしいのは、国内の大手企業が「人は交換可能なネジである」と考え、35 歳で「採掘が終わった」人材を扱い、末位淘汰による大規模なリストラも珍しくないことです。もし職の安全が切迫した問題となれば、誰が安心して仕事をすることができるでしょうか？
== 孟子は言いました：「君が臣を手足のように見れば、臣は君を腹心のように見る；君が臣を犬馬のように見れば、臣は君を国人のように見る；君が臣を土芥のように見れば、臣は君を敵のように見る。」==
このような遅れた管理レベルこそが、多くの企業が本当に効率化すべき場所です。