AWSで障害が起きてもシステムを止めない、自動化の方法：AWSで起きたことは自分たちにも起こり得る

組織のIT業務を自動化するに当たっては、1つのことを何度も何度も繰り返す機能を見つけることが出発点になる。だがそれは終着点ではない。自動化には入念なプランニングが必要だ。

[Clive Longbottom，TechTarget]

　コンピュータは1つのタスクを繰り返し行い、毎回同じ内容を出力する。だがどうすべきかをコンピュータに指示するのは人間だ。2017年2月に起きた「Amazon Web Services」（AWS）の障害では、そのマイナス面が特に大きな脚光を浴びた。システム管理者が手違いで予定よりも多くのサーバをダウンさせ、ドミノ効果を発生させて、AWSのインフラの相当部分がダウンした。

　この問題は人間の手違いから始まった。だがインテリジェントなIT自動化技術の欠如によって事態は悪化した。プラットフォームは問題を認識できず、プログラミングされた通りのことを繰り返した。AWSで起きたことは、自分たちにも起こり得る。IT自動化で最悪の事態とは、間違った処理が自動的に広がり制御不能になることだ。この事態を防ぐため、チェックを行う必要がある。

併せて読みたいお薦めの記事

AWS障害に関する記事

• AWS大規模障害はなぜ起きた？　クラウド不安を払拭するためにやるべき対策
• AWS障害に学ぶ、万一クラウド障害が起きても動き続けるシステムとは？
• 痛い思いをしてAmazon S3障害から得た教訓、「クラウド利用時のDRは大丈夫？」

攻めのIT運用自動化

• 攻めのIT運用自動化が進展、運用担当者の今後の役割は？
• 病院経営はIoTと自動化で変わる――先行事例に見る「未来の医療業務」

自動化の入念なプランニング

　ITチームがシステムをプログラミングすれば、1回のタスクを1回だけ自動化することもできる。自動化するにせよしないにせよ、最初はそのタスクを実行するスクリプトやコードを書くところから始まる。自動化しても、システム管理者が実行ボタンを押すことに変わりはない。ITシステムの自動化は、1つのタスクが1つのシステムに対して、あるいは複数のシステムに対して、違う時間に繰り返し実行される場面で効果を発揮する。

　システムのパッチや更新プログラムはIT自動化のメリットを示す典型的な実例といえる。最初のテスト用にOSパッチをシステムに導入する。システム管理者はテスト用のシステムに手動でパッチを適用し、悪影響がないかどうかを見極めた後に、本番環境に行き渡るよう配信する。

　IT部門がテストを行う際は、実際の業務で使うのと同じツールを最初から使わなければならない。これはシステム管理者とIT自動化プラットフォームの分裂を防ぐ助けになる。もしシステム管理者が同じ動作を行って、それが後にスクリプト化された欠陥になった場合、これで予想外の問題は防止できる。

　加えて、この均一性を保つことで管理者は、IT自動化プラットフォームが以後に取る一切の動作を検証できる。例えばこのツールがパッチを導入して、そのパッチが機能しない場合は、是正のために必要な措置もプログラミングできる。

併せて読みたいお薦めの記事

IT自動化を目指す

• 究極の自動化――ロボットが変える医療業務の未来とは？
• ブロックチェーンであらゆる契約を自動化する「スマートコントラクト」とは
• 灼熱オフィス解消だけではない、スマートビルがもたらす「自動化」の実力

高度なIT自動化技術

　高度なIT自動化は、トレンドの筆頭に浮上している。多くのベーシックスクリプトシステムに使われているダンプの自動化は、何もかもダウンさせかねない。