AWS未経験者なのに運用リーダー？ SCSK小出氏は「70個のドキュメントと26の業務」をどうやって引き継いだのか：「Cloud Operator Days Tokyo 2022」セミナーレポート＃4
Cloud Operator Days Tokyo 2022のセッション「AWSを触ったことのない運用者が、AWS環境のインフラ運用巻取りを通じて、運用改善をできる様になるまでのお話」にてSCSKの小出泰介氏は、AWSの未経験者がどのように運用改善を進めたのかについて語った。
企業でのクラウド活用は当たり前となった。ただ、導入のハードルが低いといわれるクラウドであっても「オンプレミスと異なる運用に戸惑っている」「今まさに勉強している」というインフラ運用担当者は多いだろう。
また、クラウドサービス自体は使ったことがあるという人でも、会社の方針で新しいクラウドを使うということは十分あり得る。そうなれば一から「クラウドの運用」を勉強し直す必要がある。
Cloud Operator Days Tokyo 2022のセッション「AWSを触ったことのない運用者が、AWS環境のインフラ運用巻取りを通じて、運用改善をできる様になるまでのお話」では、Amazon Web Services（AWS）での運用経験がないのに運用チームリーダーを任されることになったSCSKの小出泰介氏（ソリューション事業グループ マネジメントサービス第一事業本部 製造マネジメントサービス第二部 チームリーダー）の体験を紹介した。
AWS未経験者がAWS運用リーダーに
小出氏は入社以来、一貫してインフラの運用業務に従事している。現在は「リモート運用サービス」の「SEサポートサービス」を担当しており、障害対応のための原因調査や既知障害に対する対応フローと手順の作成、クラウド環境における各種運用管理、自動化の実装支援などを行っている。
小出氏がSCSKでAWSに関わるようになったのは、同社が2021年に開始した「DX（デジタルトランスフォーメーション）事業化重点領域」のプロジェクトがきっかけだ。このプロジェクトは「AWS上にサービス提供用のインフラを構築する」といったもので、2021年10月にサービス提供を開始する予定となっており、小出氏が参加したのは2021年4月のことだ。
「プロジェクトはインフラ構築チームが担当していたインフラの運用をリモート運用サービスに移管するフェーズに入っていた。『きっとメンバーの育成を見守る役割だろう』とゆったり構えていたのに、突然上長から移管作業のリーダーに任命されて焦ったことを覚えている」
なぜならこの時の小出氏は、研修で触れたことはあっても実務でAWSを使ったことがなかったからだ。
意外なところで役立った「これまでの運用」
移管作業を進めるため、まずは小出氏を含むリモート運用サービスチームの3人が、インフラ構築チームから運用を引き継ぐことになった。サービス開始までの3カ月間で運用を学び、その後は本番で運用しながら、リモート運用サービスチームの他メンバーへ運用を展開するという進め方だ。
「“AWSをほぼ知らない私”、“AWSは結構詳しいサブリーダー”、“AWSは少し触ったことがある実務担当メンバー”の3人で運用引き継ぎを始めた。この時点で運用関連のドキュメント数が70個、業務数は26個あった」
小出氏ら3人は環境を理解することから始めた。提供しているサービスの種類、システムの構成、運用ルールの調査を実施。「この段階でも大変な苦労があった」と小出氏は振り返る。
「用語はもちろん、無数にあるAWSのサービスを一から理解しなければならなかった。ドキュメントについては抜け漏れがあり、その精査作業にも時間を取られた。また、ドキュメントはあってもそこに記載されていない“暗黙知”もちらほらあり、その特定作業も必要だった」
だが、悪い話ばかりではなかった。研修とは違って実際の環境を見ながら勉強できることは興味深く、大いに勉強になったと小出氏は言う。また、リモート運用チームが作っていた「リモート運用サービス受入基準」も役に立った。
「この基準は、運用が個人の判断に依存してしまったり特定の人が運用でカバーするなど力業で解決したりすることがないように定めたものだ。この基準に従い、不足している情報を洗い出し、徹底的に可視化、文書化、標準化を実施した」
3カ月で「手順書作業の限界」に到達
3カ月間の引き継ぎを終え、本番運用を開始した。新しいチーム（リモート運用チーム）による運用を安定させるため、しばらくは手順書通りの業務を心掛けた。だが、幾つかの課題が生まれた。
「手順書通りに作業できるようにはなったが、『現在の手順が最適なのか』『もっとやりやすい方法や効率的なやり方があるのではないか』と思うことが増えた」
ただ、定例作業は無数にあるため、その全てを見直すには時間がかかる。作業自体を減らせるならいいが、不要と思える作業でも影響範囲を調査しなければならず、やはり時間が必要だ。そこで小出氏は「作業自体はなくせないだろうが、作業の省力化や自動化といったアプローチはできるはずだ」と考え、インフラ構築チームとともに定例作業の見直しをすることにした。
改善方法についてはインフラ構築チームの知見を借りて、実現難易度や効果を分析した。協議の結果、最終的に2つの定例作業を改善することになった。
定例作業1．「サーバに1台ずつログインしてコマンド実行」
まず手を付けたのは「サーバでコマンドを実行して、ログを確認する」という作業だ。「Amazon EC2」（Amazon Elastic Compute Cloud）のサーバに1台ずつログインし、コマンドを実行する。そして、コマンド実行ログをローカル環境にコピーし、内容を確認する、といったもので「作業自体は単純だが、サーバの数が多いため作業負荷の高い定例作業になっていた」と小出氏は言う。
小出氏らはこの課題を解決するため「AWS Systems Manager」を導入した。
「AWS Systems Managerを使い、『コマンドをAmazon EC2の各サーバで実行する』『コマンド実行ログを自動で保管する』という作業を自動化した。何度も同じ作業を繰り返す必要がなくなっただけでなく、AWSのコンソールで作業が完結するため、セキュリティ面でも効果があった」
定例作業2．「監視の種類ごとにログをエクスポートして振り分ける」
次に改善したのは、監視ログの退避作業だ。SCSKは監視用にトレンドマイクロの「Cloud One」を導入している。このCloud Oneの監視ログを定期的に「Amazon S3」（Amazon Simple Storage Service）に退避させる作業となる。
「監視の種類ごとにログをエクスポートする必要があり、種類が多いために作業工数も増えていた。さらにエクスポートにはレコード数の上限があり、上限を超えた場合は上限に収まるようにエクスポートの期間を調整しなければならず、作業は煩雑なものになっていた」と小出氏は話す。
この課題の解決に役立ったのはメッセージングサービスの「Amazon SNS」（Amazon Simple Notification Service）とサーバレスコンピューティングサービスの「AWS Lambda」だ。
「Cloud OneにはAmazon SNSとの連携機能がある。ログが出力されたタイミングでCloud OneからAmazon SNSに通知を出すように設定。その通知をトリガーにしてAWS Lambdaが『ログのエクスポート』と『Amazon S3にログをアップロード』という2つの作業をする。これによってログの退避作業を自動化できた」
さらに、この処理がどこかで失敗したときのために、一連の流れを監視する「Amazon CloudWatch Logs」も導入した。「ログ待避の作業は完全に自動化し、監視でエラーを検知した時のみ手動でリカバリーすればいいため、作業負担はかなり軽くなった」と小出氏は語る。
「運用チームも変わらなければならない」
このような改善活動を通じて小出氏は、開始当初は約181時間だった稼働時間を4カ月後の2022年3月には約95時間まで削減した。プロジェクトを通じて小出氏は「クラウドといってもオンプレミスの運用経験は決して無駄にならないことを学んだ」と言う。
「特に文書化や標準化などの活動はクラウドになっても重要さは変わらない。むしろ仕様変更が頻繁に発生し得るクラウド環境やアジャイル開発では、これらのスキルの重要度は増すと考えている」
小出氏は開発チーム、構築チームとのコミュニケーションについても触れる。「仕様変更が頻繁に発生する環境において、運用チームだけで改善を実施するには限界があり、開発チームや構築チームを巻き込んで活動していくことがQCD（Quality、Cost、Delivery）の観点で重要だ」と小出氏は強調する。
「今回はメンバーを選定して対応したが、メンバー全員が対応できるようなスキルアップや、運用系でのプロセスの見直しを通じ、運用チームも変わる必要があると感じた。そのため今期は、チームメンバー全員のスキルアップ向上を目的としたタスクを立ち上げ、さらなるチーム力の向上に努めていく」
Copyright © ITmedia, Inc. All Rights Reserved.