なぜ SME で DevOps 導入が失敗するのか、そして実際に機能する現実的なアプローチ

22 人規模のスタートアップの CTO が、Kubernetes、フル機能の CI プラットフォーム、Terraform、そして最新のオブザーバビリティスタックを、たった一四半期ですべて導入した。半年後、オンコールローテーションは改善するどころか悪化していた。金曜午後のデプロイは相変わらず失敗し、パイプラインを本当に理解している 2 人のエンジニアは、特定のリポジトリを触ることを密かに避けるようになっていた。これは珍しい話ではない。小規模なエンジニアリングチームが、Netflix が使うツールを買い揃えることで DevOps を導入しようとしたときの、既定の結末である。

SME にとって最もコストのかかる神話

SME のエンジニアリングにおいて最もコストのかかる神話は、DevOps が「買い物リスト」だという考え方である。チームは Spotify や Google のケーススタディを読み、ツールのスタックを目にし、そのスタックを再現すれば結果も再現できると思い込む。そうはならない。あれらの企業が信頼性の高い組織になったのは、Kubernetes を導入したからではない。彼らはすでに Kubernetes を運用するための運用の筋力を築いていたから、そしてそのスケールが本当にオーバーヘッドを正当化していたから、Kubernetes を導入したのである。

SME における DevOps は、ツールの問題ではない。ツールの衣装を着たワークフローの問題である。

自動化は運用成熟度と同じではない

多くのチームが一括りにしてしまう、有用な区別がある。自動化と運用成熟度は同じものではない、ということだ。デプロイパイプラインは自動化したものの、「なぜ午前 3 時に本番が壊れたのか」に答えられないチームは、安全性を伴わないスピードを買っただけである。今やそのチームは、バグのあるコードをより速く出荷している。

運用成熟度とは、インシデントを退屈なものにする一連の習慣である。ワンコマンドで完了するロールバック、本当に重要な 3 つの指標だけを表示するダッシュボード、オンコールエンジニアが午前 3 時でも従えるランブック、そして翌週には何かを変えるインシデントレビュー。自動化は、あなたがすでに向かっている方向を増幅する。習慣が不安定なら、自動化はクラッシュをより大きくするだけだ。

よく見かける 4 つの間違い

実践を築く前にプラットフォームを買う。 エンジニア 15 人のチームには Kubernetes は不要だ。恐らく必要なのは、サービスごとの退屈な仮想マシン 1 台と、ヘルスチェック、そして自動ロールバックである。Kubernetes はまだあなたが抱えていない問題を解決し、そして、あなたのチームがまだデバッグする準備のできていない新しい問題を持ち込む。

パイプラインを個人プロジェクトにする。 多くの SME では、1 人のエンジニアがいつの間にか「DevOps 担当」になる。彼らは自分だけが理解する美しいパイプラインを構築する。その人が休暇を取るとデプロイが凍結する。その人が退職すると、パイプラインは残りのチームが触るのを恐れる負債になる。共有オーナーシップは「あれば嬉しい」ものではない。それは、インフラストラクチャが資産であるか、それとも人質状態であるかを分ける違いである。

間違ったものを測定する。 デプロイ頻度は、変更失敗率が上昇しているなら虚栄の指標である。小規模チームはまず 2 つの数字を注視すべきだ。デプロイがインシデントを引き起こす頻度と、インシデントが発生したときに復旧までにかかる時間である。これら 2 つを無視してスピードを最適化することが、まさに安定した製品を不安定なものに変える手順である。

退屈な基礎を飛ばす。 バージョン管理されたインフラ、再現可能なローカル開発環境、シークレットの単一の情報源。これらは華やかではない。しかしそれらは、20 分で済むインシデントと、2 日かかるインシデントとを分ける違いでもある。

現場からの短いケーススタディ

ある地域の EC クライアントが、エンジニア 12 人のチーム、週 3 件の本番インシデント、そしてすべてを Kubernetes に移行する計画を抱えて我々のもとに来た。我々は移行を 6 週間停止するよう依頼した。

その 6 週間、我々は華やかなことは一切しなかった。彼らのインフラを Terraform に格納し、チームのどのエンジニアでも実行できる単一のデプロイスクリプトを書き、シークレットをマネージド Vault に移し、自動ロールバックを起動できるヘルスチェックを追加し、そして売上に紐付く指標だけを表示する 3 つのダッシュボード、すなわち注文成功率、チェックアウトのレイテンシ、決済ゲートウェイのエラーを設定した。

インシデントは週 3 件から 10 日に 1 件へと減少した。その後チームは非クリティカルなサービスを 2 つ Kubernetes に移行し、低リスクなトラフィックで学び、そのあとにようやくチェックアウトのパスを移行した。移行が成功したのは、ツールが当初計画したものと違っていたからではない。チームが先に運用の筋力を築いていたからである。

エンジニア 30 人未満のチームのための現実的なロードマップ

ステップ 1: デプロイボタンを直す。 何よりもまず、どのエンジニアでも 1 つのコマンドでメインサービスをデプロイでき、別のコマンドでロールバックできる状態を確保する。今日この作業に 1 日以上のチャット調整が必要なら、そこにこそ最大の信頼性向上の余地が隠れている。

ステップ 2: インフラをコードに落とす。 Terraform でも Pulumi でも、あなたのチームが流暢に読める方を選ぶ。目的は自動化そのものではない。何かが最悪のタイミングで壊れたときに、任意の環境をゼロから再現できる能力である。

ステップ 3: シークレットと設定を統合する。 1 つの Vault、1 つの規約、キーを回転させる 1 つの場所。dotenv ファイルやチャットメッセージに散らばったシークレットは、本番の意外な問題の驚くほど多くの割合を静かに生み出している。

ステップ 4: SME にとって本当に意味のある 2 つの DORA 指標を測定する。 変更失敗率と平均復旧時間である。四半期の間、正直に追跡する。トレンド記事ではなく、数字そのものに、次に何を直すべきかを語らせる。

ステップ 5: オーケストレーションの前にコンテナを導入する。 Docker は、運用コストのごく一部で再現性のメリットの大半を提供してくれる。Kubernetes はエンジニア 40 人か 50 人に達したとき、あるいはトラフィックが本当にそれを要求するときの決定であり、それ以前ではない。

ステップ 6: 退屈なランブックを書く。 各クリティカルサービスについて 1 ページを作成する。それが何をするか、健全であることをどう確認するか、どう再起動するか、そして戻ってこないときに誰に連絡するか。それぞれのランブックは、新入りのエンジニアに低リスクなゲームデーで従わせることでテストする。

率直な結論

DevOps はインストールする製品ではない。30 人以下のチームにとってそれは、自信を持って出荷するエンジニアリンググループと、金曜午後を恐れて過ごすグループを分ける、一連のワークフローの決定である。ツーリングは簡単な部分だ。習慣こそが本当の仕事である。

DevOps の刷新を検討していて、プラットフォームに投資する前にセカンドオピニオンが欲しいなら、MercTechs のチームは、地域の SME が過剰なエンジニアリングなくインシデントを削減できる現実的な道筋を設計することを支援してきた。我々は、あなたが必要としない高価なスタックを避ける手助けをする方が、後悔するようなものを売りつけるよりも良いと考えている。