寄稿：米国サイオス VP Cassius Rhue
私はバスケットボールが大好きだ。プレーすること、観戦すること、ゲームの大脳的な側面や思考、モチベーション、戦略や戦術についてじっくり考えたりすることが好きである。スクリーンのセットが早すぎたり、ロールが遅すぎるなど、何がうまくいって何が失敗するかを探すこと、ディフェンスやローテーションが好きだ。練習、ウォークスルー、旅行などのコーチの戦略を知るのも好きだ。だから数ヶ月前、24時間365日の可用性の世界から1日離れて休みを取った時、当然のようにバスケを観戦した。具体的には、娘の中学校のバスケットボールの練習を見に行ったのだが。
ゲームが始まって数分も経たないうちに、私は自分を抑えることができなくなった。コートの中を縦横に走り回る娘に向かって口笛を吹いたり急かしたり、「走れ！頑張れ！」と叫んだりした。娘は走り、私の声の届く範囲にいたチームメイトも走った。それからの数分間、プレーはエネルギーに溢れ、切れ味のいいカット、スムーズな動き、そしてドライブに満ちていた。
だが、それは長くは続かなかった。代わりに、ホイッスルが鳴る場面が増えた。動け、走れ、一生懸命やれ、鋭くカットしろ、ダイブだ、注意！集中しろ、学べ、直せと、より強い声がかけられた。2時間が経とうとしたとき、最後の瞬間に「練習した方法がそのまま試合でのプレー方法になる」という啓示が下りてきた。
一瞬、AI（「練習について話してるんだ。とにかく練習だ！」と連呼したアレン・アイバーソン（AI）のこと。人工知能（AI）ではない）の魂が乗り移ったのではないかと思った。そしてまた、これは可用性についても言えることだと思った。娘とそのチームメイトのことを考えた時、私のバスケへの愛が、可用性に対する情熱と重なった。理由を説明しよう。
バスケットボール戦略が可用性戦略と似ている3つの側面
- バスケでは、どんなチームにもプランが必要である。これは企業の可用性についても同様である。
- バスケでは、すべてのチームがそのプランを練習する必要がある。これは、可用性、災害復旧、特に計画保守についても同様である。
- バスケでは、批判にさらされてテストした計画は、その計画を練習したときと同じくらいうまく持ちこたえる。
エンタープライズの可用性には計画が必要
可用性、具体的には、災害、計画メンテナンス、および障害復旧戦略は、どのようなものを作成するかにかかっている。簡単に言えば、障害（クラウドの障害、サーバーのクラッシュ、ネットワークの飽和、ヒューマンエラー…これだけ言えば十分だろう）に対する計画はどのようなものかということだ。
文書化された計画はあるか。オーナーとバックアップのオーナーは明確になっているか。アーキテクチャとトポロジー（どのサーバーが何をしているか、どこにあるのか、どのチームに所属しているか、どのような機能を提供しているか、ビジネスのどの優先順位がそれに関連づけられているのか、どのようなSLO/SLAが必要か）を把握しているか。主要ベンダーはどこか、その緊急連絡先リストはあるか。チェックポイント、データ保護計画、バックアップ戦略は？また、この計画を検証するためのテスト計画と検証計画はどのようなものか、ということである。
エンタープライズの可用性には練習が必要
いい計画ができた。さて、練習についてはどうだろう。災害復旧ステップと計画外停電戦略の実施は、すべてのエンタープライズ構成に必要な要素である。
しかし、リハーサルを行っていない作戦は作戦とは言えない。その場合、それは単に実行できる可能性のあるアプローチに過ぎない。実際に練られた計画というよりは、提案に近い。第二のステップは練習である。計画の戦略をウォークスルーし、メンテナンスのタイミングをリハーサルする。バックアップとデータを復元する。前提条件と障害モードを検証するのだ。
エンタープライズの可用性にはテストが必要
計画、ウォークスルー、チェック。3つのうち2つができたところで、娘のバスケチームに話を戻そう。「非公式コーチ」として、私は最後に次のような言葉をかけた。「君たちの練習の仕方が、そのまま本番のプレーに反映されるんだ。」 試合の日、ゲームは終盤に差し掛かっていた。相手チームとは体格差があり、昨年はハーフタイムまでに試合が終わってしまった。しかし今年は、人材不足で小柄な我がチームは明らかにより多く準備ができていた。簡単に勝負がつくはずが、ほぼ同点のまま最後の1分に突入したのだ。
対戦相手のホームチームがプレスしてきた。娘のチームは、練習の間に、行き当たりばったりで無気力ではあったが、これに対抗するために準備していた。その結果は、良いものではなかった。ターンオーバー、スリーポイントを取ろうとした際の2回の重大なファウル。4対0は変わらず、時間切れ直前に絶望的な1点の失点を許し、フラストレーションは最高潮に達した。
最後に
さて、最後のポイントだが、読者諸氏は実際の停電や災害、計画的なメンテナンスに向けて、どれだけ練習しているだろうか。実際のデータ、実際のクライアントで、そして実際の危機感を持って練習しているか？上層部はどのくらいの頻度で確認しているか？（プレッシャーのかかる瞬間に上司がそばにいると、人はおかしなことや浅はかなことをしてしまうものだ。）サンドボックスやテストシステムは本番環境とそっくりなものになっているだろうか？
過去に、私はハードウェア、ストレージ、Linux OS のバージョンが本番環境とQA環境の間で異なる顧客と一緒に仕事をしたことがある。彼らがアプリケーションのアップデートで本番環境に入ったときに、災難が起きた。
ユーザーやデータ、テスト中に実行するジョブはあるか？実際の災害シミュレーションはどうか？破滅的な結果をもたらす可能性のあるハードクラッシュのテスト、オフサイトからの復旧、そして複数のポイントや複数のシステムでの同時障害をシミュレーションすることは難しいが、練習をしていないと、2時間の計画メンテナンスが複数のチームを巻き込んだ8時間にも及ぶ全社レベルの災害に変わってしまう弱点となることはよくあるのだ。きちんと練習したか、あるいは練習不足であるかによって、戦略とチームにとっての見事な勝利となるか、それともチーム、ベンダー、企業、顧客にとっての壊滅的な敗北とコストのかかる失敗となるかが決まるのである。
バスケットボールでは、批判にさらされた計画は、その計画が練習されたものでなければ持ちこたえることができない。復旧・災害計画を実施する際には、優れた計画と検証が鍵となるが、念入りな練習に勝るものはないのだ。
お問合せについてはこちら
