第12回までで、AWS OpsMate Proの開発記録の本編はいったん区切りました。今できているのは、AWSを題材にした3つの課題です。

ただ、そこまで作り終えたあとに、もう一つ考えていたことがありました。確認観点や判断基準が人によって違うという問題は、AWSだけのものではないのではないか、ということです。

そこで今回は本編の補足として、同じインフラ領域の中でも違ってくる「当たり前」と、OpsMate Proをほかの分野へ広げられる可能性について書きます。

「インフラ経験者」は、ひとつの職種ではない

インフラエンジニアとして何年も働いていても、担当してきた分野が違えば、分からないことはあります。これは経験が浅いという話ではありません。ある分野で何年も手を動かしてきた人でも、隣の分野の当たり前は、意外と共有されていないという話です。

ネットワークを長く見てきた人、サーバーの構築と運用をしてきた人、AWSを中心に触ってきた人。同じ「インフラ経験者」と呼ばれていても、持っている知識も、最初に確認する場所も、かなり違います。

それでも現場では、「インフラ経験者なら、このくらい分かるはず」と見なされる場面があります。私自身、自分が慣れている話を、相手も同じ前提で知っているつもりで話してしまったことが何度もあります。あとから振り返ると、説明を省いたというより、省いていることに気づいていなかった、という感じでした。

ネットワークを担当してきた人の「当たり前」

ネットワークが長い人は、IPアドレスとサブネットマスクを見た時点で、この二つが同じネットワークにいるのかどうかを判断します。通信がおかしいと言われれば、上流から順番に経路をたどります。

  • 名前解決ができることと、実際に通信できることは別だと考える
  • ルーティングテーブルに経路がなければ、そもそも届かないと知っている
  • L2、L3、L4のどこで止まっているのかを分けて考える
  • NAT（＝アドレスを変換して通す仕組み）は、通信を許可する機能ではないと分かっている
  • 疎通確認では、送信元・宛先・ポート・経路をはっきりさせてから試す

これはネットワークを担当してきた人には自然な順番です。ただ、サーバーやAWSを中心にやってきた人が、最初から同じ順番でこれを思い浮かべるとは限りません。

サーバーを担当してきた人の「当たり前」

サーバー側にも、同じように染みついた感覚があります。いちばん分かりやすいのは、「動いているように見えること」と「正常なこと」を、はっきり分けて見るところです。

  • プロセスが存在していても、アプリケーションが正常とは限らない
  • サービスがactiveでも、内部の処理まで正常とは限らない
  • ポートがLISTENしていても、正しい応答が返るとは限らない
  • ログはOS、ミドルウェア、アプリケーションと複数の場所に分かれている
  • ファイルの所有者と実行ユーザーの食い違いで、動きが変わることがある
  • 設定を変えたあと、reloadで足りるのかrestartが要るのかを見極める
  • ディスク使用率に余裕があっても、inode（＝ファイルの管理情報）が枯渇していることがある

ネットワーク側で「疎通もできているし、ポートも開いている」と確認できても、サーバーの中ではまだ課題が残っていることがあります。逆に、サーバーの中で完結していると思っていた不具合の原因が、依存している別のサービスやDB接続だった、ということもあります。

AWSを担当してきた人の「当たり前」

AWSにも、AWSでしか使わない確認の順番があります。私はここが自分の入口だったので、当たり前だと思い込みやすい部分でもあります。

最初に見るのは、どのAWSアカウントの、どのリージョンの話なのかです。ここがずれていると、そのあとの確認がまるごと無駄になります。

  • IAMユーザー、IAMロール、Permission Setは、それぞれ役割が違う
  • Security GroupとNetwork ACLは、そもそも性質が違う
  • Route Tableは、どのサブネットに関連付いているかまで見る
  • Internet GatewayとNAT Gatewayは、担っている役割が違う
  • マネージドサービスは、OSへログインして中を確認できない場合がある
  • CloudWatchに出ている情報と、OSの中のログは別物
  • Auto Scaling環境では、今動いているインスタンスを直接直すのが適切とは限らない
  • AWS側の設定、OS側の設定、アプリ側の設定を分けて考える
  • 実行する権限がないことと、その設定自体が存在しないことは違う

ネットワークやサーバーの経験があっても、どこを見に行くか、サービスの境界がどこにあるか、IAMとアカウント構造がどうなっているかは、また別の暗黙知です。「AWSも結局はサーバーとネットワークでしょう」と言われることがありますが、確認する場所の地図は、けっこう違います。

同じ「サイトが見えない」でも、最初に見る場所が違う

この違いがいちばん見えやすいのは、同じ事象を三人が見たときです。第1回でも少し触れましたが、「サイトが見えない」という一言に対して、それぞれこう動きます。

  • ネットワークの人は、名前解決、IPアドレス、経路、ポートを順に確認する
  • サーバーの人は、サービスの状態、プロセス、ログ、待受ポートを確認する
  • AWSの人は、CloudFront、ALB、Security Group、Route Table、オリジン設定、IAMを確認する

どれも間違っていません。むしろ、どれもその人の経験に裏打ちされた、まっとうな一手です。

問題が起きるのは、自分の得意分野を確認し終えたところで、課題全体を見たつもりになってしまうときです。「ネットワークの確認が正常だったから、これは障害ではない」「プロセスが起動しているから、サーバーは正常」「Security Groupが開いているから、AWS側は正常」。どれも、その範囲の中では正しい確認です。でも、一つの観点だけで課題全体の状態を判断することはできません。

「なんでこんなのも分からないの？」の正体

こういう場面で出てきやすいのが、「なんでこんなのも分からないの？」という感覚です。私も、口に出さないまでも、心のどこかで思ってしまったことがあります。

ただ、落ち着いて考えると、順番が逆でした。自分が何度も使ってきた知識は、使った回数のぶんだけ、説明しなくても伝わる常識に見えてきます。その知識を使う機会がなかった人にとっては、常識でも何でもありません。

そして、分野が変われば、自分も同じように分からない側へ回ります。私がネットワーク機器の設定の話をされたときに感じる手応えのなさは、たぶん、相手がAWSのIAMの話をされたときのものと、そう変わらないはずです。

大事なのは、「知らない」ことと「理解できない」ことを取り違えないことだと思っています。必要な確認観点さえ示されれば、別分野の経験者は、自分がすでに持っている知識と結びつけて、そこから先を自分で進められることが多いはずです。止まっていたのは能力ではなく、地図が渡されていなかったからだった、という見方もできます。

この違いは、インフラの外にもある

ここまでインフラの中の話をしてきましたが、この構図はインフラに限りません。分野ごとに、その分野でだけ共有されている当たり前があります。

  • ネットワーク: サブネット、経路、NAT、DNS、パケットの流れ
  • サーバー: プロセス、サービス、ログ、権限、リソース枯渇
  • AWS: IAM、アカウント、リージョン、マネージドサービス、サービス間の境界
  • DB: トランザクション、ロック、インデックス、実行計画、整合性
  • 開発: クラス、インスタンス、API、例外処理、非同期処理、依存関係

DBを長く経験してきた人でも、業務で開発をしてこなかったなら、クラスやインスタンスの感覚がすぐに出てこないことはあると思います。逆に、開発を長くやってきた人でも、サブネットやルーティングを担当したことがなければ、同じことが起きます。

これは「DBの人は開発を知らなくて当然」という話ではありません。担当してきた業務によっては、知らないことがあっても不思議ではない、というだけです。どの分野にも、外から見ると気づきにくい当たり前があります。

OpsMate Proで、課題データに持たせたもの

ここで、これまで作ってきたものを振り返ります。OpsMate Proでは、課題データの側に次の情報を持たせました。

  • 課題の目的と背景
  • 前提条件
  • 確認する順番
  • 正常例と異常例
  • 判断基準
  • 必須証跡
  • 完了条件
  • 不足しやすい確認観点の補助

並べてみると、この中にAWS固有の機能はほとんどありません。IAMやCloudFrontといった具体的な中身はAWSのものですが、器のほうは違います。これは「その課題で必要になる暗黙知を、個人の頭の中だけに置かず、課題の側へ移すための構造」です。

念のため、現時点で実装できているのはここまでです。Webサイト接続障害、IAM権限追加、環境調査・引き継ぎという3つの課題を、共通のCase／Stepモデルと3カラムUIに載せ、進捗を保存し、証跡と判断結果がそろわないと完了できない制約をかけ、ローカルのルールによる補助を右側に置いた、AWS実環境を変更しないプロトタイプです。実AI接続やBYOK、認証、AWS実環境への接続は入っていません。

他分野でも同じ器が使えるか、試してみたい

そう考えると、一つ気になることが出てきます。この器は、AWS以外の分野でも成り立つのか、ということです。

ネットワークの課題として「拠点間で通信ができない」を扱うなら、事象と発生条件、送信元と宛先、IPアドレスとサブネット、VLAN、デフォルトゲートウェイ、ルーティング、ACLやFirewall、NAT、DNS、パケットキャプチャ、原因の判定、証跡、完了条件、といった順にStepを並べられそうです。

サーバーの課題として「Webサービスが起動しない」を扱うなら、サービス状態、プロセス、ポート、OSログ、アプリケーションログ、設定ファイル、実行ユーザー、ファイル権限、ディスク、メモリ、依存サービス、DB接続、原因の判定、証跡、完了条件、という並びが考えられます。

DBの課題として「SQLの応答が遅い」を扱うなら、発生条件、正常時との比較、実行時間、実行計画、インデックス、統計情報、ロック、同時実行数、データ量、CPU・メモリ・I/O、クエリの変更、証跡、完了条件、といったところでしょうか。

ただ、これらはすべて構想です。NW OpsMate Pro、Server OpsMate Pro、DB OpsMate Proのようなものに手をつけたわけではありませんし、同じ設計がそのまま通用すると思っているわけでもありません。今あるのはAWSの3課題だけで、それ以外は「展開できる可能性がある」という段階です。課題データを変えるだけで対応できるのか、それとも器のほうに手を入れる必要があるのか。そこは今後の候補として考えていて、同じ設計が成立するか試してみたいと思っています。

もう一度、第1回の問いへ

第1回で書いたのは、「できない人」と呼ばれる状態の多くは、その課題の常識を知らないだけかもしれない、という違和感でした。今回書いてきたのは、その「常識」が分野ごとにまったく違う、という当たり前の事実です。

分野が変われば、何年やってきた人でも、その課題の常識を知らない側へ回ります。私も回ります。だからこそ、人を評価する前に、その課題に必要な観点が見える形になっているかを先に考えたい、と思うようになりました。

OpsMate Proで作ったのは、AWSの答えを教えてくれる仕組みではありません。AWSの課題を確認するために必要な観点を、課題の側へ持たせた仕組みです。その考え方が、ネットワークやサーバーやDBでも成り立つのかは、まだ分かりません。

ただ、試してみたい気持ちはあります。AWS以外の課題でも、同じCase／Step設計が使えるのか。そこを課題データを変えることで確かめられたら、このシリーズで考えてきたことが、もう少し先まで届くのかもしれません。