コードをハックしてプロジェクトを永久に管理することはできません。ある時点で、プロジェクトを稼働させる必要があります。
かつてはプロジェクト開始から数か月または数年経ってから稼働開始の瞬間を迎えていたかもしれませんが、今日では DevOps と継続的デリバリーのおかげで、技術者は毎日稼働開始の瞬間に直面しています。
中には、グリーンフィールドアプリケーションの本番環境への導入を初めて開始する企業もあれば、既存のアプリケーションのアップグレードに取り組む企業もあります。また、それほど恵まれていない企業は、大規模な移行作業に取り組んでおり、数百万件ものミッションクリティカルなレコードをレガシーシステムから新しいインフラストラクチャに移行しています。
時々、TSB のような問題に遭遇します。
稼働開始の瞬間は、たとえ熟練したITプロフェッショナルにとっても、最も恐ろしい出来事の一つとなり得ます。不十分なテスト、不適切なキャパシティプランニング、冗長性や災害復旧の欠如など、様々なミスが、電源投入から数秒、数日、あるいは数年後にプロジェクトを台無しにする可能性があります。
IBM、英国のIT崩壊した銀行TSBに「テストシステムの改善」を勧告
続きを読む
ソフトウェアプロジェクトでは、チームがプロジェクト開始を決定する瞬間にすべてが繋がります。何ヶ月も前の計画不足は、その瞬間が来るずっと前に頓挫させてしまう可能性があり、これは決して珍しいことではありません。スタンディッシュ・グループは2016年のカオスレポートで、ITプロジェクトの19%が完全に失敗し、56%が問題を抱えていると述べています。
1996年の打ち上げ後に爆発したアリアン5ロケットの失敗は、すべてが適切に準備されていない状態で誰かがスイッチを切り替えた際に何が起こり得るかを示す、最も顕著な例の一つです。このケースでは、複数のエラーが重なり合って打ち上げが失敗に終わりました。慣性基準ソフトウェアにおける単純な浮動小数点から整数への変換エラーが、誘導システムを停止させました。より徹底的なテストを行っていれば、この問題は発見できたはずです。第二の原因は冗長性の欠如でした。バックアップシステムはありましたが、全く同じソフトウェアが動作していたため、全く同じ方法で故障しました。
2017年1月に発生した米国税関・国境警備局（CBP）のシステム障害は、それほど目立った出来事ではありませんでした。何千人もの旅行者が全米で何時間も列に並ばなければなりませんでした。CBPはコンピュータシステムを旧式のメインフレームから最新の環境にアップグレードしていましたが、適切な計画がありませんでした。国土安全保障省監察総監の報告書によると、システム容量テストの不十分さが原因であると指摘されています。また、事業継続プロセスの不備が復旧を困難にしたことも指摘されています。
では、よくある問題とは何でしょうか。また、失敗やしくじりの可能性を最小限に抑え、結果として顧客、従業員、管理者の怒りを招かないようにするにはどうすればよいでしょうか。
オートメーション・コンサルタンツのディレクター、ジェフ・カンリフ氏は、クライアントのソフトウェアライフサイクルを管理し、大規模顧客のプロジェクトを定期的に本番稼働させています。彼の最大の教訓は？それは「事前準備を怠らないこと」です。成功しているチームは、当日の惨事を避けるため、何ヶ月も前から対策を講じています。
「解決策としては、こうした移行を確実に成功させるための手順とチェックリストを導入する必要がある」と彼は述べた。
これらの対策には、詳細な導入計画と、万が一問題が発生した場合の対応策が含まれます。導入チームは、依存システムの所有者が本番稼働プロセスに支障をきたすような変更を行わないよう、変更凍結リストを作成する必要があります。
その他の重要な対策としては、組織内外のすべての利害関係者に何が起こるかを正確に説明するコミュニケーション プランが含まれます。
大規模な移行を計画する際には、リソースリストを必ず作成し、導入チームが人材とスキル不足に陥らないようにすることが重要です。最後に、ServiceNow のタイムラインのように、システム移行に関連するタスクをタイムラインにまとめます。このタイムラインには、この移行チェックリストに記載されている Go/No Go ミーティングを含める必要があります。これにより、実装チームは新しいシステムの導入準備が整った時期を判断できます。
同じアプリケーションであっても、アプローチ、リスクに対する許容度、ステークホルダー管理、クライアントの成熟度、システム統合能力など、これらすべてを考慮する必要があります。
スムーズな稼働開始プロセスを確実にするために、もう一つの重要な点は、プロジェクトが他のどのシステムに影響を与えるかを理解することです。オートメーション・コンサルタンツのカンリフ氏と同じくディレクターを務めるフランシス・ミアーズ氏は、プロジェクト初期における最も重大な失敗の一つは、スコープの適切な把握が不十分であることだと指摘します。
これは、時間の経過とともに有機的に成長し、既存の開発者の多くが去ってしまった、ドキュメントが不十分なレガシー システムに特に当てはまります。
「既存システムの依存関係について、十分な情報が得られていないことがよくあります。そのため、徹底的な調査が必要です」とミアーズ氏は述べた。従業員にシステムの使い方について尋ねることは、この点で役立つ可能性があるが、社内政治や時間的制約により、必ずしも彼らが対応してくれるとは限らない。
技術的なアプローチも有効です。ランタイム分析ツールを使用して依存関係を監視することは可能ですが、月末にしか実行されないジョブなどを検出するために、長期間にわたって実行することが重要です。
テストもプロセスの重要な部分ですが、ユニットテストだけに注力してはいけないと、QuoStarのCEOであるロバート・ラザフォード氏は警告しています。「（企業は）特定のユーザーベースやチームを対象にテストを行いますが、十分なストレステストは行いません」とラザフォード氏は言います。「本番環境への切り替えを行うと、パフォーマンス関連のあらゆる問題が発生します。」
新しいシステムがユーザーの期待どおりであることを確認するために、ユーザー受け入れテストも重要です。
これらはほとんどのプロジェクトで共通する要件ですが、PRINCE のような広範なプロジェクト管理方法論以外には、特に古いシステムと新しいシステム間の移行時に稼働を開始するための業界標準のプレイブックは存在しないと専門家は述べています。
「プロジェクトは一つ一つ全く異なります」と、ECSのプログラムディレクター、ドン・トムリンソン氏は語る。20年間、大規模な導入プロジェクトに携わってきた彼は、あらゆる経験を積んできた。「たとえ同じアプリケーションであっても、アプローチ、リスク許容度、ステークホルダー管理、クライアントの成熟度、システム統合能力など、あらゆる要素を考慮する必要があります。」
トムリンソン氏は、システムの本番稼働には3つのアプローチがあると考えている。1つ目は開発者にとって最も有利なアプローチだ。既存ユーザーがおらず、他のシステムに依存しない、全く新しいプラットフォームだ。こうしたプロジェクトの本番稼働は、既存ユーザーがいるシステムを適応させたり移行したりするよりも容易だ。なぜなら、これらのシステムへのスイッチを入れ替えても、他のインフラストラクチャやアプリケーションに影響がないからだ。
旧システムから新システムに移行する場合、他の2つのアプローチから選択する必要があります。1つ目はウォームトランジション（並行運用とも呼ばれます）です。これは、リスクを最小限に抑えるために、新システムを旧システムと並行して運用するものです。2つのシステムを並行運用することで、ITチームはユーザーをグループごとに移行することができ、全員が旧システムから新システムへ一斉に移行する「ビッグバン」型の移行とは異なります。
ITチームは、他のユーザーほどミッションクリティカルではない、影響度の低いユーザーグループから移行を開始できます。移行が進むにつれて、これらのグループを注意深く監視し、問題を発見することができます。これにより、問題がユーザーベースのごく一部にのみ影響するように、問題を局所化することができます。新規ソフトウェア開発プロジェクトや既存システムのアップグレードでは、カナリアリリースが同様の目的で、ソフトウェアのバージョンを一度に少数のユーザーグループに展開します。これは、頻繁なリリーススケジュールで作業するDevOpsチームにとって一般的な手法です。
この段階的な並行移行は、Red Badger の Joe Paice 氏と彼のチームが、顧客向けの Web ベース システムからクライアント向けの別のシステムに移行する際に行ったことです。
「システムを試験的に導入できる、個人的に知り合いの顧客が何人かいました」と彼は述べ、その後、同社がユーザーのセグメント化を開始したと説明した。同社には、常に同じユーザーが選択されるようにしながら、新しいシステムを利用するユーザー数を増減できるアルゴリズムがあった。「バグに遭遇しましたが、それは予想通りでした。顧客データを手動で修正することで、それらのバグから回復することができました。」
ペイス氏によると、同じバックエンドデータベースに依存するフロントエンドシステムを移行する場合、多くの場合、同じバックエンドへの書き込みを継続できるという。ただし、新しいシステムが正確なデータを書き込んでいることを確認する必要がある。ペイス氏はさらに、コンテナをベースとする新しいアプリケーションはKubernetesポッドからのトラフィックをミラーリングできるため、トラフィックルーティングの柔軟性が向上すると付け加えた。既存のレガシーデータベースと、並行して稼働する新しいデータベースのテストバージョンの両方にトラフィックを書き込み、新しいシステムが古いデータベースと一致するレコードを生成するかどうかをテストするといったことも可能だ。
最後の本番稼働オプションは、誰もが避けたい「ビッグバンカットオーバー」です。これは、計画停止期間中にシステムを別のシステムに移行し、その後すぐに古いシステムを廃止するものです。
「これはシステムを一括で切り替える場合です」とカンリフ氏は述べた。「時には後戻りできない状況もあります。」製造工場の制御システムを移行する場合、コードの切り替えが可能な唯一の時期が工場の大規模なターンアラウンド中である場合、ターンアラウンド期間に間に合わせるために、すべてを一括で実行しなければならない可能性があります。
ビッグバン方式の移行シナリオには、2つのシステムを並行して運用するコストがかからないというメリットがあります。デメリットは、徹底的なテストによってリスクが伴うことで、その結果、そのリスク軽減が最優先事項となることです。カンリフ氏は、ここでは「リハーサル」が不可欠な活動だと述べています。このテストでは、すべてのデータを含む移行全体を実行しますが、古いシステムを停止するまでは実施しません。
こうした切り替え作業における課題は、データの移行です。「旧システムがオフラインになった瞬間に、コピーを開始しなければなりません。これには数時間かかることもあり、試運転でその時間を計測しました」とカンリフ氏は語ります。
課題は、システムが以前のシステムと同じように動作しないことに気づき、それを報告すべき欠陥だと考えるユーザーが多くいることである。
実際の移行を行う際には、リハーサル中にレガシーシステムから収集したデータを使用できる可能性があります。ただし、リハーサル以降にレガシーシステムが生成した新しいデータも収集する必要があります。データベースのトランザクションログは、この際に非常に重要な資産となることがよくあります。
最終的な移行が実際に行われるまでに、チームはスクリプトを用いて可能な限り多くの手順を自動化しておく必要があります。ロールバック用のスクリプトも必ず用意しておく必要があります。「適切なロールバック計画があれば、古いシステムをオフラインにした時点の状態に戻すことができ、データ損失は一切ありません」とカンリフ氏は述べています。
ロールバックはネットワークレベルから上位レベルまですべてをカバーし、トラフィックを旧システムに戻すルーティングや、データの同期を維持するためのデータベース変換をサポートする必要があります。「これはリハーサルの一部であるべきです」とカンリフ氏は述べ、さらに注意点として、「場合によっては、完全にクリーンにロールバックしてデータへの影響を回避することが不可能ではない場合もあります」と付け加えました。
結局のところ、どのような導入戦略を採用するにせよ、人的要因を忘れないことが重要です。企業は、導入後、サポートコールが入り始めると、たとえシステムが正しく動作していたとしても、大量のコールが予想されるため、人員管理の方法を学ぶ必要があります。
SQSグループの品質管理責任者であるイヴァン・エリクソン氏は、「初期段階では何らかのサポートを提供するつもりです。問題は、多くのユーザーが、新しいシステムが以前のシステムと動作が異なることに気づき、それを報告すべき欠陥だと考えることです。初期段階では、多くの批判が寄せられます。」と述べています。
準備はできていますか？そんな仕事は私たちが望んでいないでしょう。高速道路の追い越し車線で車のエンジンを交換するようなものです。もし誰かがあなたにこの仕事を任せたら、綿密な計画と十分なテストが、次の恥ずかしいニュースの見出しになることを避けるのに役立つでしょう。®
