「故障するまで現状維持」と「早期かつ頻繁にリリース」の最適バランス

組織であれば必ず、「故障するまで現状維持」と「早期かつ頻繁にリリース」という対立する 2 つの方針に直面します。このブログ記事では、どうすればエンタープライズ・コンシューマーがソフトウェア業界の急速な変化に適応できるか模索しています。

午前 9 時にレコーディングされた曲が午後 1 時にはチャートトップに躍り出て、午後 5 時には懐メロになる。そんな状況を揶揄する有名なラジオ DJ の気分を味わっているのが現代のソフトウェア業界です。ソフトウェア・プロデューサーは当然のようにコンシューマーを果てしない変化の渦に放り込み、コンシューマーは疲弊しきっています。

変化の痛み

変化は実際に痛みをもたらします。しかし、その痛みは真新しいものではありません。

私が小さなエンジニアリング大学のジュニアシステム管理者だった 1980 年、そう冴えているとも言い難いアイデアがひらめきました。管理していた冷蔵庫サイズのシステムの回路基盤が非常に汚れていたため、掃除機で汚れを吸い取ろうと考えたのです。何も難しいことはありません。基盤を取り出し、掃除機をかけ、バックプレーンのスロットにも掃除機をかけ、再度取り付けます。数十の基盤に掃除機をかけ終えた頃には、購入当時を思わせる輝きを取り戻していました。ただし、電源は入りません。

ベンダーのフィールドサービスに連絡すると、サポート担当技術者がレベル 2 の技術者を同伴してやってきましたが、結局レベル 3 の技術者を呼び出し、あっという間にオシロスコープ、メーター、鰐口クリップ、ケーブル、その他諸々の診断機器を抱えたサポート技術者軍団が集結し、システムの隅々まで調べ上げ、その間ユーザーは指遊びなどしながら待ち続けることになりました。

最終的に数日かかったものの、システムは息を吹き返しました。そしてフィールドサービス技術者のテリーは、私を指さしながらこう言いました。「いいかグレッグ、今後は故障していないなら触るんじゃない」

私がこの教訓を忘れることはないでしょう。

しかし、何事にもバランスは重要です。

何もしないことの痛み

2014 年 12 月、私は eBay で安く購入した HP 製 750 GB SATA ドライブの RAID セットを搭載した NFS サーバーを中心に、ファイル/プリントサーバー、メールサーバー、Web サーバー、その他いくつかの仮想サーバーで仮想マシン・インフラストラクチャを運用していました。そして 2014 年 12 月 20 日の土曜日、私自身がアポロ 13 号体験と名付けた事件を経験しました。

午後 5:30 頃だったと思います。私は階下に降り、750 GB ドライブ 2 台で黄色の障害ランプが点灯していることに気付きました。スペアがあったので故障したドライブを交換し、家族で食べる夕食をテイクアウトするために車で Applebees に出掛けましたが、その間に RAID セットの再構築が開始しました。自宅に戻ると、別のドライブが故障していました。RAID 10 セットは停止し、構築済みの仮想サーバーもすべて停止していました。家族は私抜きで夕食をとり、私は真夜中に夕食をとりました。

復元には成功したものの、それは簡単な作業ではありませんでした。ファイル/プリントおよび電子メールサーバーには適切なバックアップがありましたが、新しい Web サーバーは一度もバックアップしていなかったため、ゼロから仮想マシンを再構築しなければなりませんでした。Brewster Kahle 氏の母親は 1970 年代のある時期から亡くなるまで、視聴できるニュース番組をすべて録画していましたが、私はこれに大きな感謝を捧げます。この母親のおかげで、Brewster Kahle 氏は web.archive.org の立ち上げに至り、私は Wayback Machine から再構築に有用な画像や動画を示す Web ページやポインターのコピーを取得することができました。真夜中を過ぎてクリスマスの朝が明ける頃には、オンラインに復帰していました。新年を迎える頃には、オフラインだった間の時差ぼけとストレスからの頭痛も解消しました。

ほぼ災害と言えるこの出来事は、自分の過失によるものです。私が原因です。故障した 750 GB ドライブは、ファームウェアの問題があるため安価で購入できたもので、以前から特に理由もなくオフラインに切り替わることがありました。更新は可能でしたが、適用するのが面倒だったこと、長い間運用していたこと、故障してはいなかったことなどを理由に修理せずにいました。正気を疑うほどのバカげたリスクを背負い込み、ほぼ完全シャットダウンの憂き目にあいました。

思い当たることはありませんか？手元にあるもので問題ないのに、なぜ更新に時間を割くのかと、お客様に聞かれることも少なくありません。「古いバージョンのバグは、最悪のタイミングででしゃばり、復旧のためにその後 5 日間ほどの睡眠を奪い去るから」がその答えです。しかも、サポートチェーンに連なる誰も、故障した旧バージョンの奇妙な癖を覚えていないため、すべて自分だけで解決しなければなりません。

それだけではありません。

技術的負債による痛み

Digital Equipment Corporation (DEC) は、1975 年に VAX/VMS を製造した際に、今後の VMS バージョンでは旧バージョンとの互換性を永久に維持することを約束しました。DEC はその約束を守りました。1990 年代に入っても、初代 VAX11/780 と同じバイナリーが動作する当時の最新システム (当時) でデモを行いました。しかし、この約束が仇となり、VMS ではさらに高速化したハードウェアへの対応が遅れ、最終的に DEC は迅速に対応できる競合他社に完敗しました。DEC は今や歴史のちりとなって消え、元 DEC 関係者は未だにあの時こうだったら、と思い返しては頭を抱えています。

技術的負債を積み重ねることは、搾取目的の金融業者に借金するようなものです。金利が下がることはありません。しかし、人は変化を嫌うため、あまりにも多くのコンシューマーがそれを受け入れてしまいます。

人は変化を嫌う

ここで、変化に対するお客様のフィードバックを少し紹介します。

• 「早めに失敗して失敗から学ぶという概念はここでは通用しない」

• 「テストとラボに人員が割ければ、そもそも問題など発生しない」

• 「当社のリスク許容値はゼロ」

• 「sev 1 や sev 2 インシデントを発生させることはできない」

• 「運用エクセレンスにおいて、これまでにない可視性を実現できている」

• 「変化は十分に計画され、熟考されなければならない」

• 「ネットワークの一時停止を回避し、すべてのスケジュールを明確にする必要がある」

私のお気に入りのフィードバックはこれです (元のフィードバックより少し控えめな表現にしています)。

• 「18 カ月ごとに冷蔵庫を買い換えなくてはならない、しかもその冷蔵庫から新しく得るものは何もないとしたら、あなただって怒るでしょう」

以下は、お客様のフィードバックに対するフィードバックです。

• 早期に実行すれば、早めに失敗して失敗から学ぶことは可能です。

• ゼロリスクは神話です。進歩を受け入れ、早期に素早く失敗することでリスクを軽減できます。

• 新しいアイデアをイノベーション・パイプラインに通すことで、sev 1 および sev 2 インシデントを回避できます。

• イノベーション・パイプラインでは以下を実行して、運用エクセレンスを継続的に改善できます。

  • 変化について十分に計画および熟考し、

  • 予測可能なスケジュールに従い導入する。

• IT インフラストラクチャは、市販の冷蔵庫ではありません。通常の冷蔵庫に対してサイバー攻撃を仕掛ける人はいません。その点で IOT 冷蔵庫は異なり、公共のインターネットに接続された小規模ウェブサイトを提供しています。この場合、問題を回避するために継続的な更新が必要です。

現在、Rube Goldberg すら呆れるような複雑さでソフトウェア層を重ねたお客様も存在しますが、これはすべて安定性を免罪符に陳腐化したプロセスや機器との互換性を維持するためのものです。しかし、いわゆる安定性は錯覚かもしれません。いずれは故障により大惨事を引き起こすか、維持することで進歩が阻まれ組織自体が陳腐化するでしょう。

ジレンマ

変化し続ける現代の世界で成功するためには、コンシューマーにもアジリティが求められます。サイバー攻撃者は絶えず弱点を探り、顧客獲得競争は熾烈化し、ソフトウェアベンダーはバグ修正や新機能を猛烈なスピードでリリースしています。何もしないことでリスクが軽減されることはありません。何もしないということは、システムの陳腐化に伴いより大きなリスクを受け入れるということです。

一方で、アジリティにもリスクが伴います。スムーズにアップグレードできることは少なく、多くの場合で新しいバージョンには新しいバグが発生し、不安定なインフラストラクチャが醜聞を生み、罰金が課されることもあります。それで済むならまだいい方です。911 の呼び出しシステムや電力網、あるいは重要な医療システムに障害が発生したらどうなるか想像してみてください。現代社会が当然のように使用しているシステムに障害が発生すれば、後に続くのは混沌です。

何もしないままではいられません。先に進めなくなります。答えは出ましたか？

ソリューション

イノベーションを事業活動の一部として受け入れましょう。つまり、あらゆることを再考するのです。数年にわたるテストサイクルや大規模なアップグレードにより全員を混乱に巻き込むのではなく、より洗練されたラボ環境での実証を通じて、継続的に改善を積み重ねましょう。改善の可能性がインテグレーション段階を無事通過したら、現実的な合成ワークロードに基づく自動テストを実施します。実稼働に向けた準備が完了する頃には、高品質テストの試練を経て、バグも修正されているはずです。

この過程をイノベーション・パイプラインと呼びます。以下はそのビジョンです。

• まず、組織横断的な小規模のイノベーション・プロジェクトから開始します。

  • 多くがすぐに失敗します。

  • しかし、いくつかのプロジェクトは、

    • 第一段階の統合ラボに進み、

    • さらに多くが失敗します。

• 脱落しなかったプロジェクトが QA ラボに進み、

  • ここでテストチームが統合に関する問題を明らかにし、修正します。

• その後、実稼働準備ラボに移動します。

  • テストチームは、現実に即して合成されたワークロードを使用してスケールの問題を抽出し、修正します。

• 最後に、実稼働環境に移行しますが、

  • その場合もすべて予測可能なスケジュールで行います。

このビジョンを導入することで、「早期かつ頻繁にリリース」と「故障するまで現状維持」の両面から、スケールの問題を解決できます。これは組織全体で考え方を変えることを意味します。初期投資は必要かもしれませんが、財産が吹き飛ぶほどではありません。代わりに、蓄積された技術的負債と、それに伴う金利の負担が、測定可能な実際の費用と機会の両方で軽減されます。

Red Hat は、お客様の現状を明確にし、進歩を享受できるよう支援します。

詳しくは、Red Hat Openvideo Labs に関する 2 分間の動画 をご覧ください。これは、インターネット上のどこかに存在する単なる仮想サンドボックスではありません。お客様側のエンジニアと当社のオープンソース・エキスパートがパートナーとなり、共にアイデアを事業成果へと変換するための没入領域です。無料の電子書籍 ではさらに詳しく説明していますので、ぜひダウンロードしてご覧ください。または、Red Hat Services までお問い合わせください。

「故障していない」場合でも、改善は可能です。顧客もそれを歓迎するはずです。他社は決断しないでしょう。自分自身に対する挑戦を止めないでください。