AWSで起きたことは自分たちにも起こり得る
AWSで障害が起きてもシステムを止めない、自動化の方法
組織のIT業務を自動化するに当たっては、1つのことを何度も何度も繰り返す機能を見つけることが出発点になる。だがそれは終着点ではない。自動化には入念なプランニングが必要だ。
コンピュータは1つのタスクを繰り返し行い、毎回同じ内容を出力する。だがどうすべきかをコンピュータに指示するのは人間だ。2017年2月に起きた「Amazon Web Services」（AWS）の障害では、そのマイナス面が特に大きな脚光を浴びた。システム管理者が手違いで予定よりも多くのサーバをダウンさせ、ドミノ効果を発生させて、AWSのインフラの相当部分がダウンした。
この問題は人間の手違いから始まった。だがインテリジェントなIT自動化技術の欠如によって事態は悪化した。プラットフォームは問題を認識できず、プログラミングされた通りのことを繰り返した。AWSで起きたことは、自分たちにも起こり得る。IT自動化で最悪の事態とは、間違った処理が自動的に広がり制御不能になることだ。この事態を防ぐため、チェックを行う必要がある。
自動化の入念なプランニング
ITチームがシステムをプログラミングすれば、1回のタスクを1回だけ自動化することもできる。自動化するにせよしないにせよ、最初はそのタスクを実行するスクリプトやコードを書くところから始まる。自動化しても、システム管理者が実行ボタンを押すことに変わりはない。ITシステムの自動化は、1つのタスクが1つのシステムに対して、あるいは複数のシステムに対して、違う時間に繰り返し実行される場面で効果を発揮する。
システムのパッチや更新プログラムはIT自動化のメリットを示す典型的な実例といえる。最初のテスト用にOSパッチをシステムに導入する。システム管理者はテスト用のシステムに手動でパッチを適用し、悪影響がないかどうかを見極めた後に、本番環境に行き渡るよう配信する。
IT部門がテストを行う際は、実際の業務で使うのと同じツールを最初から使わなければならない。これはシステム管理者とIT自動化プラットフォームの分裂を防ぐ助けになる。もしシステム管理者が同じ動作を行って、それが後にスクリプト化された欠陥になった場合、これで予想外の問題は防止できる。
加えて、この均一性を保つことで管理者は、IT自動化プラットフォームが以後に取る一切の動作を検証できる。例えばこのツールがパッチを導入して、そのパッチが機能しない場合は、是正のために必要な措置もプログラミングできる。
高度なIT自動化技術
高度なIT自動化は、トレンドの筆頭に浮上している。多くのベーシックスクリプトシステムに使われているダンプの自動化は、何もかもダウンさせかねない。
どんなIT自動化プラットフォームでも、是正機能が求められる。これはロールバックの形態を取ることもある。この場合、プラットフォームが直接対処できない問題を検出すると、システム全体、あるいは特定部分を、機能していたときの状態まで戻す。ロールバックプロセスでは続いて担当者に通知を出し、その人物がログなどのデータを使って問題の原因を突き止め、修正のための措置を講じる。
代替として、システムがパッチを受け入れない理由を自動化ツールが認識し、それを受け入れられるように変更を加えることで対処する方法もある。この種の修正は先手を打たなければならない。IT自動化プラットフォームはパッチの配信を試みてパッチが適用できないシステムを洗い出す前に、ターゲットとする全システムを検証しなければならない。問題のあるシステムは直接的な修正を行うか、アラートを出す必要がある。状況によっては、修正のためにハードウェアを変更する必要が生じたり、IT自動化技術の範囲外で完全な入れ替えが必要となったりすることもある。
IT自動化のもう1つのトレンドは、プラットフォーム機能としての再利用性だ。手順やタスクの再利用ができるかどうかは、組織が選択する自動化への道にかかっている。例えば、N台の仮想サーバ上の特定のワークロードをスクリプトでプロビジョニングしたとしても、それはユーザーがその特定のワークロードを実行したい場合に行う手動作業を保存するにすぎない。だが、そのツールでワークロードコンテナを作成すれば、スクリプトを使ってAというワークロードをN台の仮想サーバにプロビジョニングできる。同じスクリプトはB、C、Dなどのワークロードにも利用できる。
ワークロードA、Bなどの内容は必要に応じて変更でき、指定したワークロードをプロビジョニングする方法も調整できる。プロビジョニングとパッケージ自動化の間の抽象層はオブジェクト階層を形成し、プラットフォームユーザーの柔軟性は高まる。システム管理者はワークロード作成側からスクリプトAを選び出し、それをプロビジョニング側からのスクリプトBで覆って、目指す結果を達成できる。
組織はOSのレベルを越えてITタスクを自動化できる。同じアプローチはアプリケーションスタックや、コンテナ、エンドポイント端末、ファームウェアなどにも適用できる。現時点でこうしたシステムを管理するためには、高給取りだが間違いも犯す人間が必要とされている。
IT自動化は必要性の領域に入った。物理、仮想、クラウドリソースを組み合わせ、パブリック、プライベート、ハイブリッドモデルを横断するプラットフォームを着実かつ安定的に運用することは、IT業務を自動化しない限りは不可能だ。
ITチームは今すぐ、どの自動化技術が合理的かを検討しなければならない。反復可能性の欠如がITパフォーマンスにかかわる重大な懸念となる前に。
次のステップ
自動化はITのレベルを越えて、組織全体で進行している。ビジネスプロセス自動化（BPA）も、IT部門にとっての強みとなるはずだ。IT部門は円滑で効率的なBPA利用のために必要な技術を提供する必要がある。モノのインターネットが組織に浸透する中で、何千台ものデバイスが継続的なセキュリティ対策とメンテナンスを必要とするようになる。そのための自動化機能への追加投資も見越しておかなければならない。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
技術文書・技術解説
[Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分？ 不足する対策を16項目でチェック -
製品資料
[株式会社ウェーブスプリッタ・ジャパン] 100Gbps対応の光トランシーバーはどう選ぶ？ 10分で分かる選定のポイント -
製品資料
[株式会社フィックスターズ] 組み込み開発の生産性と機密性を両立、自社環境で構築する「セキュアAI」活用術 -
製品レビュー
[ServiceNow Japan合同会社] 問い合わせの約9割を自動で解決、AI主導の自律型CRMがもたらす業務変革の全貌 -
市場調査・トレンド
[ServiceNow Japan合同会社] AI活用が業務自動化で止まる理由は何か？ 調査で判明した課題と変革への道筋
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4％
-
2
なぜOpenAIやAnthropicのAIは「脱走」したのか 情シスが迫られるエージェント統制
-
3
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは？
-
4
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
5
Anthropicが明かす AIは入力データを「どこまで覚えているのか」
-
6
GitHubが指摘 AIが書いた「おそらく動くコード」が招くシステム崩壊
-
7
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
8
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
9
ただなのに「12時間以内の復旧」も要求 無償OSSに商用レベルを求める企業の末路
-
10
「にゃんこ大戦争」がAWSを脱出した理由 無停止移行に潜む“わな”
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
5
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
6
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
情報セキュリティ対策早分かりガイド：25の自社診断で弱点と解決策を理解
-
9
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
10
AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー