お疲れ様です。最近は振られる検証タスクをこなしています。少しずつ要領を掴めてきた感があります。
（とはいってもまだまだですが・・）
この間まではまるまる1ヶ月かかっていたのが3週間、2週間と縮めることができました。
検証用の手順書もない中、作業を進めていたので、混乱していた時期もありました。
そこで、これまでの作業を振り返って検証タスクのマニュアルを作ってみました。
検証以外でのタスクを任されるときでもこれは役に立つだろうと思い、備忘録として残したいと思います。
全体のフロー
検証タスクの進め方として大まかなフローを紹介します。大きく分けて９つになります。
①検証の目的を把握するためにミーティングする
・どのサービスを使いたいのか？
・顧客のシステムに実装するのか？
・期限日は？
②前提条件・環境設定・パターンの確認
・サーバーのOSやインストールしておくべきソフトウェアのバージョン、デフォルトなのか確認をする。
→キャプチャを撮る、公式のドキュメントURLを控えておく
・揮発性のある設定なのか？その都度設定しなければならないものか？
→公式からの回答のURLは控えておくこと
③作業手順を作成
・必ずテキストベースをコピーして作業手順書を作成する
④仕組みの理解と調査
・なぜその設定が必要なのか？AWSの設定と仕組みを理解して書き出すこと
⑤作業手順をフェーズごとに整理する
・一つひとつの作業を目的を書いて、それらをフェーズごとに整理して書き出すこと
⑥命名リストを作成する
・それぞれのサービスごとに命名をしてテキストエディタに書き出すこと
⑦フェーズの検証を行う
・確認するコマンド、実行コマンドを使用して確認すること。
→キャプチャを撮る
⑧キャプチャを撮る
・これまでの作業内容を整理して検証成功、失敗のエビデンスとしてキャプチャを撮る
⑨検証結果を書く
・成功したのか失敗したのか検証結果を書く
それでは早速詳細を見ていきましょう。
目的の把握
まず検証依頼の目的を把握しましょう。チャットでも良いのですがなるべくミーティングを10分ほど時間をとってみて認識の擦り合わせをしてください。
その際に必ず次の３つを確認してください。
・どのような問題を解決したいのか?
検証するにあたり、どんな問題があったのか？なぜ解決したいのか？検証を行うことは何かしらの課題があります。
例）
毎日、動作しているジョブを休日、祝日も動作している。
使用するコストが発生するので休業日は動作させたくない
これらの課題をハッキリさせておきましょう。
・何のサービスを使いたいか？
依頼者によっては〇〇と〇〇のサービスを使用して検証してもらいたい。などの要望がありますので聞いておきましょう。
他のAWSサービスと組み合わせて使いたい、もしくは既存のAWSサービスとの兼ね合いがあって〇〇を使用したい、などの意図があります。
・顧客のシステムに実装するものか？
内部で利用したいものなのか？どの顧客の、どの環境に実装するものなのか？を聞いておきましょう。タスクの進め方やチームのメンバーに周知する必要も出てくるためです。
・期限日は？
この検証タスクはいつまでに締めるのかを聞いておきましょう。検証はうまくいかないときはかなり長引きます。
顧客の環境に実装するものだと損失を生むこともあります。優先順位を決める上で重要なので聞いておきましょう。
前提条件と環境設定・パターンの確認
・環境設定
作業に必要なAWSのサービス、サーバーのOS、必要な設定、インストールしておくべきソフトウェアなどがあります。調べてバージョンがいくつなのか。デフォルトで入っているものなのか、インストールする必要があるのかを確認しておきましょう。
その際に必ずキャプチャを撮っておくこと、インストールするならそのコマンドを入れたキャプチャを撮りデフォルトで入っているなら確認コマンドの実行結果のキャプチャを撮っておきましょう。
・パターンの確認
それは一度設定すれば何度も使用できるものなのか？起動するたびに設定しなければないものか？
こちらも顧客の環境に実装するものなら公式のドキュメントを使用しましょう。
もしくはサポートからの回答を取ること。その際の公式からの回答のURLは控えておくように
作業手順書を作成する
・テキストベースで作成する
エンジニアとして当たり前だと思いますが一文字でも間違っていたり１つでも設定手順をすっ飛ばしていたら想定する動作になりません。
なのでまずは参考記事から設定する項目をそのままコピペして作業手順を組みます。ボタンの名前、設定項目の名前をそのまんまコピペすること。
手入力で行うのも作成するのも良いですが人は間違えますし１つでも空白が入ったり小文字が大文字にでもなっていたら通りません。まずはコピペした設定項目を作業の順番通りに並べてみましょう。
コピペせずにそのままマネコンで検証するのもありですが初学者はちょっとタンマ。
なぜその設定が必要なのか？なぜその値を、そのポリシーを入れないといけないのか？仕組みを理解する必要があるのです。
仕組みを理解する
仕組みを理解しておかないと作業を進めていく中でエラーが発生した場合、なぜエラーが発生したのか？理由がわからなくなります。
なので一度設定項目、入れる値を書き出したら目的に沿った調査をしてみましょう。
インプットをして仕組みを理解してください。
例）
［GetCalendarState］のポリシーをなぜロールに追加する必要があるのか？
↓
[AWS Systems Manager]のステートマシンがカレンダーで登録した情報を呼び出す必要があるから
↓
ポリシーを追加しないとステートマシンが動作してもエラーが発生する。
命名リストを作成する
検証なので厳密に命名規則は作成しなくても良いですが作業を円滑に整理して進めたい場合は、それぞれのサービスごとに役割を命名し命名リストを作成しておき、専用のメモファイルに控えておきましょう。検索する際にとても便利です。
例）
■EC2
・Name
・server-dev-pri-01
・bastion-pub-01
■Amazon EventBridge
・ルール
・ec2-status-check-01
・ec2-status-check-02
作業リストをフェーズごとに整理する
先ほどまではまずは作業手順をざっくばらんに書き出しました。
そうしましたら次はそれをフェーズごとに整理しましょう。これは何の目的があるのかというと、、
例えばフェーズ1の設定が正しく設定されていないとフェーズ2の設定がうまく行かない、エラーが出る。など、
もしエラーが出た場合の原因がどのフェーズで正しく設定されていないか原因を特定するためです。例えば、、仮に全ての設定がうまくいっていれば・・
■フェーズ1→正しい設定をしている
・設定1
・設定2
■フェーズ2→正しい設定をしている
・設定1
・設定2
■フェーズ3→正しい設定をしている
・設定1
・設定2
■フェーズ4→正しい設定をしている
・設定1
・設定2
■フェーズ5→正しい設定をしている
・設定1
・設定2
結果：検証成功！
となります。しかしこれが、、フェーズごとに整理していないとどうなるのか？
・設定1→？
・設定2→？
・設定3→？
・設定4→？
・設定5→？
・設定6→？
・設定7→？
・設定8→？
結果：検証失敗！
え？どこで設定を間違えた？？となるんです。これだとどこから改善すれば良いのかわかりませんよね。
フェーズで整理して作業を進めるとどこで間違えたのわかります。
■フェーズ1→正しい設定をしている
・設定1
・設定2
■フェーズ2→正しい設定をしている
・設定1
・設定2
■フェーズ3→間違えた設定をしている◀︎
・設定1
・設定2
■フェーズ4→正しい設定をしている
・設定1
・設定2
■フェーズ5→正しい設定をしている
・設定1
・設定2
結果：検証失敗！
なのでフェーズを分けて整理し、一つのフェーズが終わるごとに確認する必要があります。次の項目に続きます。
フェーズごとにテスト・確認を行う
フェーズが１つ完了したら必ず成功したことを確認するためのコマンドやテストを行って下さい。正しく設定ができれば挙動が想定したものなるはずです。
一つのフェーズで正常な挙動をすること、もしくは正しい実行結果が出るのを確認してから次に進めてみましょう。
キャプチャを取得する
各フェーズごとの検証が成功したらエビデンスとしてキャプチャを撮っておきましょう。キャプチャの撮り方の基本としては、設定前と設定後の挙動を撮りましょう。いわゆるビフォーアフターですね。
またたくさん撮ることになるのでフェーズごとのフォルダを作成し、その中にまた一つずつの設定ごとのフォルダを作成して整理しておきましょう。
検証結果
検証結果、失敗したのか、成功したのか、想定した動きになったのか、ならなかったのか、顧客のシステムに実装することになったのか、見送りになったのかを書いておきましょう。
私もここに書いてあることを完璧にこなせているわけではありません。改めて書いてみて重宝するなぁと自画自賛しております笑
ぜひいいね！をください！励みになります。
他にもこんな記事を書いていますのでよければぜひ！