マイクロソフトのクラウドへの移行の中での Microsoft Azure のインシデントと変更の管理の自動化
Azure
本ポストは以下の記事の翻訳です。
マイクロソフトのクラウドへの移行の中での Microsoft Azure のインシデントと変更の管理の自動化 – Inside Track ブログ
クラウドの運用化
2021 年 6 月 10 日 | Pete Apple
Pete Apple は Microsoft Digital のクラウド サービス エンジニアであり、Microsoft Azure サービスを活用したマイクロソフトの業務 IT の変革を押し進めています。(写真: Jim Adams | Inside Track)
マイクロソフトが自社でクラウドに移行することは、冒険であったと確実に言えます。
マイクロソフトは新しいテクノロジにより多くの IT プロセスを変革し、プロセスを完全になくすことができた事例もありました。また、運用の正常性を再評価する必要がありました。監視とパッチ適用、アーキテクチャ、変更管理などの進化する運用機能に歩調を合わせることができるかどうかを再評価する必要もありました。
マイクロソフトはクラウドへの移行を通じて、情報技術インフラストラクチャ ライブラリ (ITIL) と以前呼ばれていた運用モデルに基づき、会社の IT サービスをビジネスのニーズに合致させることに重点を置いています。
マイクロソフトはこれまで、1 年あるいは 2 年のアーキテクチャを作成し、それで問題ありませんでした。現在では、少なくとも四半期ごとに魅力的な新しい機能を評価しています。私たちのチームはアジャイル (俊敏) になるために学ぶ必要がありました。それは文字通りの意味でもあり、隠喩的な意味でもあります。
– Pete Apple (Microsoft Digital クラウド サービス エンジニア)
サービス エンジニアの視点から見ると、マイクロソフトのクラウドへの移行の中で、設計と管理機能はほとんど進化しませんでした。これを聞くと、皆さんは驚かれるかもしれませんし、やや安堵するかもしれません。理解してアーキテクチャの設計に組み込むべき新しいテクノロジは確かにありますが、その作業を行うチームは基本的に同じままです。ただし、Microsoft Azure について学び、Microsoft Azure がコンピューティング、ストレージ、データ、ネットワークをどのように扱うかについて学ぶことは素晴らしい機会となりました。
[マイクロソフトのクラウドへの移行に関するシリーズの他の記事もお読みください: 「マイクロソフトのクラウドへの展開で学んだこと、落とし穴、妥協」、「マイクロソフトのクラウドへの展開の中での Microsoft Azure ソリューションの管理」]
継続的に関心を持たなければならなかった 1 つの事柄を挙げるとすれば、それはクラウドの進化し続けるアーキテクチャの変化です。Microsoft Azure チームは、従来と比べてより頻繁に新しい機能をリリースしています。マイクロソフトはこれまで、1 年あるいは 2 年のアーキテクチャを作成し、それで問題ありませんでした。現在では、少なくとも四半期ごとに魅力的な新しい機能を評価しています。私たちのチームはアジャイル (俊敏) になるために学ぶ必要がありました。それは文字通りの意味でもあり、隠喩的な意味でもあります (「アジャイル手法」をご覧ください)。
Microsoft Azure を活用し、サービスのターンアラウンド時間を短縮することで、業務を進化させ、生産性を向上させることができました。よい例として、変更管理の統制があります。
4 年以上前、私たちのチームは社内利用者から標準的な変更要求を数多く受け取りました。当時私はプライベート クラウドを運用しており、「仮想マシンを作成してください」、「SQL をインストールしてください」、「オペレーティング システムをリビルドしてください」など、多くのさまざまな要求があったことは想像に難くないでしょう。それぞれの要求はマイクロソフトのシステムの中で変更記録となり、72 時間という急を要するサービス レベル アグリーメント (SLA) に従って作業を行うために、システム エンジニアにただちに割り当てられました。
皆様の会社でも似たようなことはあるでしょう。
マイクロソフトがクラウドへの移行の歩みを進める中で、私たちは、内部カタログにあるすべての変更の種類を詳しく調べ、自動化できるものはすべて自動化しました。
届いた変更注文の数と種類を確認し、高度なスクリプト機能、System Center Orchestrator、Azure テンプレート、Azure Automation を活用することによって、それらの変更アクティビティの多くを自動化できることが判明しました。これによってヒューマン エラーを減らし、SLA を向上させることができました。また多くのケースで、私たちのチームが変更を手動で実施するのを待つのではなく、社内利用者が自らデプロイを行うセルフサービス アプローチを実装できました。
現在、Microsoft Azure サービスによって、マイクロソフトの内部チームはチーム独自の変更をセルフサービスで実装でき、面倒な「チケットを開く」というモデルをスキップできます。
インシデントの部分でも、同じ方法によってより効率的になることが分かりました。
最適化されたアーキテクチャを使用してインシデントと変更の管理を自動化することに少し抵抗感を感じる人もいるかもしれませんが、私たちの組織にとっては非常に有益でした。
– Pete Apple (Microsoft Digital クラウド サービス エンジニア)
Microsoft Azure への移行が増加すると、顧客向けアプリケーション開発者は、より迅速な DevOps タイプのデプロイメントを実行するために、Azure サブスクリプションへの直接アクセスを要望するようになりました。これは多くの場合、アプリケーション開発者がほぼ即座に問題やインシデントを見つけることを意味します。アプリケーション開発者には、これまでのようなインシデント管理を担当する中心的なチームは不要になりました。
これを受けて私たちは、インシデント管理をハイブリッド モデルに移行しました。このハイブリッド モデルでは、アプリケーション チームは、Microsoft Azure Monitor と Application Insights のアラートが自らのチームに直接送信されるようにすることを選択できます。その場合でも、インフラストラクチャ アラートとサービス停止は中央のチームに引き続き転送されるようにすることができます。これによって、アプリケーション チームの中には、サービス信頼性アクティビティを自らのチームで処理するために必要なスキルが向上したところがありました。また、それらの同じチームにおいて、解決とバグ修正までの時間が短縮されました。私たちが維持したものは、重大インシデントの管理を支援できる中央の「エスカレーション管理」機能です (新しい用語では「LiveSite」と呼ばれます)。
最適化されたアーキテクチャを使用してインシデントと変更の管理を自動化することに少し抵抗感を感じる人もいるかもしれませんが、私たちの組織にとっては非常に有益でした。変更管理でいくつかのオーバーヘッドを取り除くことで、場合によっては 30 ～ 40% のコスト削減が実現し、利用者に結果を提供する速度が向上しました。利用者の仮想マシンを構築するために、以前は 48 ～ 72 時間の SLA を締結していました。現在では、利用者自身が Microsoft Azure で 30 分かからずに仮想マシンを立ち上げることができます。
チームは、アラートおよびインシデントを Microsoft Azure DevOps チームが直接受け取り、必要な場合に限り中央の IT 部門にエスカレーションするように選択できます。これにより、ビジネスに影響する項目をより迅速に解決できるようになります。
Microsoft Azure を全面的に使用し、クラウド パターンをアーキテクチャの設計に組み込むことで、変更管理作業の時間とコストを節約でき、同時に SLA とカスタマー エクスペリエンスを改善できます。これは、サブスクリプションとサービスに対して長期的にどのような意味があるでしょうか? この「クラウドの運用化」ブログ シリーズは継続され、マイクロソフトがクラウドへの移行を通じて得た洞察や学んだことを共有していきますので、最新情報を定期的にチェックしてください。
Microsoft Azure サービスが以下の点でどのように役立つかをご覧ください: ハイブリッド環境での運用タスクの構成と自動化、効率的な管理のための ARM テンプレート ドキュメントの使用、次世代のビジネス アプリとインフラストラクチャを管理するためのフレームワークの提供
