Scribble at 2023-02-20 14:05:15 Last modified: 2023-02-20 14:11:03

受託案件で AWS にウェブ・サーバを建てているサイトがあって、既にキャンペーンでの利用は昨年中に終わっているため、現在は静的なページを表示しているだけである。このサイトには、うちで運用している SAKURA のクラウドに建てたコーポレート・サイトのサーバから１分おきに疎通確認のスクリプトを cron で叩いていて、タイムアウトしたら Webhook で Google Chat の「【情シス】Server Status」という専用ルームへ通知するようになっている。

これまでのところ、合計で10回ていどは通知があったけれど、サーバが落ちているわけではない。さきほども２ヵ月ぶりくらいでタイムアウトした通知が届いていたのでサイトへアクセスしてみたが、特に変わった様子はない。そらそうだ。１時間に１アクセスくらいしかなくなっているキャンペーン・サイトでサーバが落ちていたら、考えられる原因は (1) 何らかの経路で EC2 インスタンスに侵入されたか、(2) ハードウェアの故障か、(3) 途中経路のネットワークに障害が起きたかのどれかだろう。もちろん、どれであろうと起こりうるけれど、その蓋然性から言えば相当に低い。そして、サイトへ実際にアクセスして確かめるという、当たり前の習慣が身に着いてさえいれば検証のしようはいくらでもある。

そして、毎回のように（もちろん仕事だから当たり前のことだが）サイトへアクセスすると何の問題もない。そして、そういうタイムアウトは過剰に不安を感じなくても起きることなのだと知っていれば、そういう通知が届いたことを無暗に怖がる必要もないわけである（そして、それがなぜなのかをエンジニアが理解していなければ、結局はわれわれの「上流」であるウェブ・ディレクター、広告代理店、そしてトップ・クライアントの全員が怖がるわけである。われわれが彼らよりも桁違いの知識と経験を持たなければ、しょせんウェブの案件で損をするのはわれわれ自身なのだ）。

本当のところウェブのエンジニアで通信技術に素養がある人は非常に少なく、この手の素養を持つ人の大半はゲーム業界やインフラ業界といった特定のサービス事業者に人材が偏っているわけだが、最低でも学部レベルの（デジタル）通信工学を学んでおけば、通信というものが成立するには色々な条件があり、リクエストからレスポンスまでのレイテンシ全体において介在する色々なリスクを考慮し、そして原則として避けられない限界というものがあることを理解できるようになる。

たとえば、データ通信というのは光の速度や途中の経路にある通信機器のパフォーマンスを越えられないなんてことすら無視して、世界中の相手と即座に通信できるかのようなラノベ的なことを言うバカが上場企業にもたくさんいる。また、途中の経路でケーブルが破損したり、ケーブルの劣化だとか周囲からの電磁波による干渉で（とりわけ無線だと）著しくパフォーマンスが落ちる。そして、そもそもリクエストからレスポンスまでに起きるプロセスは個別の事象であって、僕の自宅でサイトへアクセスする条件と、他人が他の場所からアクセスする条件は物理的に全く違うため、いわゆる「おま環」事案なのかどうかを切り分ける必要が常にある。われわれは理屈としての一般論は理解しているけれど、物事を仕事として判断するときは、常に個々の事例や状況に則しての判断から出発することになり、それらを潰していって初めてサーバに問題があるのかどうかという、僕らにしか解決できない原因に辿り着くこととなる。そうでない限り、たとえば NURO で通信障害が起きているのを何とかしろなんて言われても、そんなことは NURO 以外の誰に解決できるというのかというわけである。