orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

日本がもし100人の村だったら、ひとり情シスになる理由

f:id:orangeitems:20210912001637j:plain

 

十年前ほど大流行しましたよね。「世界がもし100人の村だったら」。世界に100人しかいないと仮定するといろいろわかりやすくなる、というのが話題を席巻しました。

 

世界がもし100人の村だったら

 

この本も2021年版にアップデートして再度出したらいいのになんて思うのですが、この本の考え方は今でも通用すると思います。

さて、今回の話題をする前に、日本のITエンジニアはどれぐらいいると思いますか?。

 

hrzine.jp

 各国のIT技術者数を国・地域別で見ると、米国がトップの477.6万人、ついで中国の227.2万人、インドの212万人と続く。この3か国で世界のIT技術者の約43%を占めており、IT大国として大きな存在であることが分かる。

 なお、日本は109万人で世界第4位。しかし、トップの米国の2割強、3位のインドと比較しても約半数に留まった。

 

ということで、100万人強ということは、100倍すると1億人。

つまり、日本がもし100人の村だったら、ITエンジニアは一人しかいないということですね。ざっくり言えば。

 

私の体感的にも、100人未満の情報システム担当って一人のところが結構多い印象です。会社が少人数の時は専任の担当者すらいない、「ゼロ情シス」から始まり、社員が増え始めて仕事が増えてやっと「ひとり情シス」(専任担当)が誕生する。100名程度ではひとり情シスなのは当然で、そこから二人以上になるのはもっと先。

こういった各社の情シス担当の状況調査をご紹介します。

 

japan.zdnet.com

 ひとり情シス・ワーキンググループが2020年12月に実施した「ひとり情シス実態調査」と「中堅企業IT投資動向調査」によると、従業員100~500人の中堅企業におけるひとり情シスの割合は32.6%と微増していました。増減の変化を調べたところ、ここ数年では大きな変動は見られませんでした。しかし、この内訳を詳細に調べると、新しい傾向が見えてきました。

 さまざまな調査によると従業員100人以下の中小企業におけるひとり情シスの割合は5%未満です。平均すると、従業員が80人を超えた辺りからひとり情シスを配置する傾向です。ただし、この傾向は業種やビジネスモデルによって異なります。今でもITに重きを感じていない中堅企業では、従業員が100人を超えても情シス担当者が存在しないこともあります。

 

www.atpress.ne.jp

ひとり情シス・ワーキンググループは、従業員100名から500名までの独立系、大手企業グループ会社系の日本国内全ての中堅企業を対象に、「ひとり情シス実態調査」と「中堅企業IT投資動向調査」を実施しました。約半数の中堅企業が、来年度の景気状況を不安視しているものの、IT予算を増加する企業は38.2%であり、減少する企業の26.3%を上回っています。同時に、「ひとり情シス」を取り巻く環境にも新しい変化が見られます。その速報値を報告いたします。

 

日本全体で1%しかITエンジニアがいないのだから、100人の会社であれば一人専任を置ければそれは心地よい割合です。

しかし、世の中の会社が往々にしてDXで慌て始めたり、政治家がデジタルを連呼し始めている状況にて、結局はITエンジニアが少なすぎるというのが現在の状況にあると思います。

しかも、日本の場合は状況が特殊で、ITエンジニアはSIerや、SaaS/PaaS/IaaSサービス企業など、独立した会社に集まっています。

だから、ユーザー企業側に著しく人材が不足し、情シスを設定できないということが言えると思います。上記調査にもありましたが、ユーザー企業の情シス担当者の半分がITベンダー出身とのことです。

結論としてはですね、明らかに日本にはITエンジニアが少なすぎる、ということです。

これも、学校教育において「国語・数学・理科・社会・英語」の5教科から長い間逃れられないところの悪影響です。「情報」という教科ができたり、プログラミングが学習に組み入れられたりと変化はあるものの、まだまだ日本ではニッチな分野だと思います(ここ最近は人気職業になりつつありますが・・)。

日本がもし100人の村だったら、理想は30人くらいはデジタルがわかっていないとまずいんじゃないかな、と言う実感はあるのですが、残念ながら、お一人と言った状況です。

だから、ノーコードやローコードなんて概念が今流行し始めているんです。残りの99人でもデジタルが扱えるように、と。

ただ、それは本質じゃないですよね。教育分野からどんどんデジタルシフトして、せめてふたり情シスぐらいにはなりたいですね、日本も。

 

コロナ禍終わったらどうなるかっていう話

f:id:orangeitems:20210910141450j:plain

 

コロナ禍が終わるとするじゃないですか。まだ終わってませんが。

そしたら、大量のテレワーク人がオフィスに帰りますよね。

週5フルに急に戻るとは思えませんが、それでもたくさんの人々がオフィス通いを再開するようになる。

なぜかというと、他の会社、つまりお客さんもオフィスに戻るからです。そうするとこっちもオフィスにいた方が何かと便利ですよね。呼べるし行けるし。

Web会議?、いや面倒でしょ。とにかく会いに行きますよね。もうしばらくWeb会議でしかお会いできなかったから、まあ話に花が咲きますよね。遠距離恋愛かっつーの。

そしたら今度飲みに行きますか、なんて話になって、歓楽街も連夜の大フィーバーになるんでしょうね。忘年会シーズンが半年ぐらい続くみたいな。

で、社内は社内で、みんな集まって、コロナ禍での反省会みたいなものもたくさん開かれるでしょう。ウチの会社、こういうところイケてなかったよね、から始まり、こうしませんああしませんの大検討会議が自然発生的に起こるでしょう。

やっぱり直接会ってないと言えないことってたくさんありますから。会話の間とか雰囲気とか、直接会っているときってたくさんの情報がそこにあるんだなと感心するものですよ。

で、ITの世界ですが、もうみんな忘れかけていると思いますが、「2025年の崖」っていう課題があって、ここまでにいろいろデジタル的な課題を解決しておかないと、崖から真っ逆さまに落ちるよっていうことを経産省が主張してたわけです。

で、主張しはじめたのは2019年ごろだったんですが、ちょうどコロナ禍が起こって、みんなそれどころじゃなくなったよね、と。

もう2022年にワープなんです。だからもう2025年まで後3年みたいな話になっちゃってる。

2025年の崖って、SAP ERPの保守切ればかりが言われますけど、Windows 2012やら、Redhat 7やら、Java 8やら、今度はWindows 10までが加わってきました。

※ほとんどは拡張サポートを契約すれば2025年から先もサポートされるのですが、余分にお金払います?って話です。

みんな今を凌ぎ切ることに勢力を使ってきたけど、もしコロナ禍終わったら、急に新しい現実と向かい合うことになるのですよ。しかもパンデミック対応の反省という大きな課題を抱えて。

もうね、皆がDXとは何かということを意識しなくても、しゃべってることはDXの話ばかりになると思いますよ。だって、テレワークしていた人たち、普段Twitterやらネットニュースやらを見て、自分の会社がいかに遅れてたかをかなり学習してますから。

きっと、オフィスに集まった時に、なんでウチにはこれがないんや!ってなりますよ。で大商談会の開始ですよ。きっとどこの営業もひっぱりだこになって、むしろ外回りする時間がないと言って「Web会議でおねがいしゃす!」ってなりますよ。そしたら営業効率爆上がりですね。多分コロナ禍で、どこの営業部員も営業ツールの使いこなし、相当ウデを上げていると思います。

商談決まりそうなら行けばいいですし。それまではWeb会議連チャンで十分です。

このコロナ禍、まだ緩和に浮かれるにはもう少し早くて、どういう風に新型コロナとつきあっていくか、新しい内閣や衆議院議員選挙を経る必要があります。また、アメリカもどうも今年中はオフィス回帰は様子見にするようです。

 

www.bloomberg.co.jp

米マイクロソフトは10月4日までに米国オフィスを完全再開するとしていた計画を取り下げた。新型コロナウイルスの今後の感染状況は予測不可能だとして、オフィス再開の新たな予定は提示できないとした。

 

一方で、ワクチン義務化までバイデン大統領は踏み込んできています。

 

www.cnn.co.jp

バイデン米大統領は9日、連邦政府職員や一部の医療従事者に新型コロナウイルスワクチンの接種を義務付けるとともに、大規模雇用主に対して従業員のワクチン接種か週1回の検査を確認するよう要請する方針を明らかにした。

 

2022年は、きっとDX一色になると思います。そこまで想像力を働かせて、2021年の残りを過ごしていけば良いのではないかと思います。

 

報告書に書いてはいけないNGワード

f:id:orangeitems:20210910003422j:plain

 

最近、世の中はすごくシステム障害に厳しくなっていて、一般のテレビのニュースを見ていてもシステム障害の話をするようになりました。

システム運用を仕事にしている私にとってはとても胃の痛くなるような時代が到来しましたが、社会的責任がいよいよ高まって来たと考え、誇りをもって仕事をしていきたいと思います。

さて、このシステム障害と一体となる報告書。仕事柄よく読むのですが、NGワードが存在します。このワードが書いていあると大抵報告書としては落第点だと思っています。そんなNGワードをいくつか紹介します。

 

 

総点検

総点検って、多分、大掃除、くらいの意味しかないです。

全部とは何かを決めるのは難しくて、必要な要素を全て挙げていくこと自体が本来は作業なのですが、「もー、全部!」みたいに短気を起こして、目につくところを片っ端から対応していく様を言います。

こういうことをすると、十中八九漏れます。なぜなら、優先順位をつけていないから、重要・緊急であるものが後ろ廻しにされる確率が上がるからです。

それより、重要・緊急なものをリストアップし、それだけは絶対に漏れないようにするほうが、コストが限られている中では最善策です。

 

徹底

徹底って、すごく前向きさにあふれている言葉なんですが、よくよく意味を考えると、お気持ちなんですよね。この対応策を徹底します!、何て言いますが明日には徹底しても、一年後に徹底しているかまではこの言葉は何も保証しません。

対策に「徹底」と書かれていたら、即、私は書き直させますね。どう徹底するかの仕組みを書き出し、徹底と言う言葉は外すように、と。

そうすると、全然徹底する方法論は考えていなかったりして、便利な言葉である一方、何の意味も持たない言葉でもあります。

 

丁寧に

今後、丁寧に対応・・なんて言う時のその丁寧って、何を示すのでしょうか。

これもお気持ちです。

失敗するときは、丁寧にやってもダメです。むしろ丁寧にやらなくても失敗しない方法を考えるのが対応策です。

気持ちが丁寧なのではなく、具体的なプロセスが細かく気が配られていれば、別にわざわざ言う言葉でもありません。

 

強化する

この、強化という言葉にはウソが多いです。

現状どうで、未来はどうなのか。これを誰でも理解可能な表現で示すことができれば、それ自体が強化であり、中身を示さず「強化します」なんて報告書はボツです。

例えば、「監視を強化いたします。」という文において、じゃあどういう風に監視を強化するの?、と聴くとします。それは・・、と、そこから先のことを知りたいのであって強化するキリッじゃないんだよ、と思うことしばしばです。

 

整備する

整っているのか、備わっているのかは、読み手が判断することであり、整備しますで片づけられても訳が分かりません。

これも、報告書を書く側のお気持ちであって、中身を表現することで、「おお、整備したんだね」と言わせてほしいですね。

 

顧客目線

顧客目線でオペレーションを見直します、みたいな使われ方をします。

この言葉を使われると、今まで顧客目線じゃなかったんかい・・と思ってしまいますね。

これは、改善策ではなく、むしろ今まで欠けていたことを恥じるべきで、顧客の前で堂々と言うことではないと思います。

 

 

とりあえず考え付くまま6つを例に挙げました。

結局は全て、言葉や精神論でごまかして、具体的なTo Do、プロセスを明らかにしない態度が裏にあると思います。なぜそうなるかというと、そこまで深掘りできていないからというのと、そもそも報告書を書く人が無知、ということの2つあります。

もう、謝る方も謝られる方も両方やったのでわかりますが、顧客は別に、誠心誠意謝って欲しいなんてほとんど思っていなくて、それより原因究明、対策の立案、そして実施を、スケジュール感を持ってやってほしいと思っています。

いくら土下座したって、システムや運用保守のプロセスが良くなるわけじゃないですからね。

ところが報告書では、それをぼかしてくる。

意外と、大会社の報告書すら、ちゃんと書かれていないことが多いので最近いつも読むようにしています。具体的な例はあえて出しませんがここ最近の案件を見ていくといろいろありますので、興味があれば調べてみてくださいね。

 

フリーランスが2023年10月1日に導入されるインボイス制度で窮地な件

f:id:orangeitems:20210908002201j:plain

 

二日くらい前のTwitterで、「インボイス制度がヤバい」と聴いていたので、少し勉強してみた。ほとんどのフリーランスを潰しにかかっていると。いやあ、そりゃあ言い過ぎでしょう、またまたネットはいつも大げさだねぇと思ってたかをくくっていたのですが、情報収集すればするほど、これは確かにヤバいですよ。

何がヤバいって、おそらくほとんどのフリーランスに発注していた担当者は、これはインボイス制度実施後は企業に頼んだ方が絶対いいな、と思うはずです。もしくはフリーランスを契約社員にするなど、給与で支払った方が良いと言う判断もあろうと思います。

インボイス制度の専門的なことをここで話すと少し難しい数字の話になるので、この記事ではできるだけわかりやすく順番に話します。だいたいの概要をつかんだ後に、専門的な記事を読めばより正体がわかるでしょう。

で、なんで冒頭のようにフリーランスに頼みたくなくなるのか。これは、フリーランスは今までは年間の売上が1,000万円未満なら消費税を支払う必要が無い、ということが重要なポイントになります。

でも企業のシステム開発などで考えればわかると思いますが、ユーザーが10億円のシステム構築をSIerに頼んだとすると、最終的に国はその10%の1億円を消費税として徴収したいと思いますよね。だから、ユーザーは11億円をSIerに支払います。

これで、SIerが1億円を消費税として国に納めるかというと違っていて、10億円のシステムを作るのに年収900万のフリーランスを100人集め1年稼働させたたとします。そうすると9億円をフリーランスに支払ったので、1億円がSIerの手元に残りますよね。で、1億円のうち10%を消費税としておさめますから、1,000万しか消費税を支払わないことになります。

お、それは国はお困りになりますよね。だってユーザーは1億円分消費税を払っているんだから。残り9,000万円はどこにいった、と。ここで本来ならば、年収900万のフリーランスたちには実は990万支払わないとおかしいんです。増えた90万は消費税です。そして、本来はフリーランスは90万を消費税として納めたら、90万x100人、つまり9000万円がここで国に消費税として合計徴収されるはず、でしょ?。

しかしここで邪魔になるのが「年間の売上が1,000万円未満なら消費税を支払う必要が無い」っていうルールです。フリーランスたちは消費税免税だー!って支払わないものですから、ユーザーが消費税を1億円支払っても、国には1億円どころか1,000万円しか入らない現象ってのが起きてしまっていたわけです。

そこで「インボイス制度」ですよ。

SIerが消費税を計算するときに、売上から仕入れに使ったお金を引くというのは、上に書いた通りです。ここではフリーランスに支払った金額を引いてましたよね。

インボイス制度施行後は、ここでのSIerは消費税を計算するとき、免税対象のフリーランスに使った金額を、売上から引けなくなってしまうのです。

つまり、消費税が免税のフリーランスの消えた消費税分は、SIerが支払えよ、というそんな制度です。免税対象者を抜け道にした消費税節減ができなくなる、ということです。

インボイス制度施行後、SIerの立場だったらどうするか。

①フリーランスに支払っていた分にかかるだろう消費税をSIerが払ってあげる

これしかなくなるんですが、SIerからすれば実質10%値上げと同じになるんですね。でもフリーランスの懐に入るのはこれまでと同じ金額。

で、SIerの予算は決まっているでしょう?。そしたらおそらく10%程度の値切った金額で発注をかけてくるようになるはずです。

年間の売上が1,000万未満のフリーランスで、しかも10%値切るって結構な金額。その上そこから所得税や社会保険料も支払わなければいけないですからね。

もしくは、

②フリーランス側もちゃんと消費税を支払うか

です。そしたら企業は売上から今まで通り引けるので、今まで通りの金額で発注してくれると思いますが、今度はフリーランス側が受け取る金額から消費税を払わなくてはいけなくなる。つまり、フリーランスが消費税を乗せて契約しないと割に合わなくなる。

これ、どこからどう見ても、1,000万円未満のフリーランスの人にはインボイス制度って何のメリットもないのは必然ですね。ちなみにこれまで1,000万円以上稼いでて消費税を支払ってきた人には何の変化もありません。

 

・・・と、ここまでの概要は、以下のページで勉強しました。

 

wezz-y.com

 

繰り返しますが、2023年10月から施行です。

実質、売上1,000万円未満の消費税免税が無くなるのと同じ意味を持つよな・・。と思っています。フリーランスより、企業で稼ぐ方が全然いいように思いますし、1,000万円以上のフリーランスが成り立つなら起業して会社にしたほうがこちらもメリットが多いように思います。

いつの間にこんなことに・・、と勉強になった件でした。

 

AWS、Direct Connect障害の報告書を意訳してみた

f:id:orangeitems:20210907164624j:plain

 

はじめに

2021年9月2日に話題となったAWSのDirect Connect障害について、詳細なレポートがAWSから発行されています。

 

aws.amazon.com

 

ただ、日本語がちょっと読みにくいと感じたので、わかりやすく意訳してみました。

内容についてはうのみにせず、原文をお読みください。

 

以下、意訳

--------------------------

日本時間2021年9月2日に東京リージョン(AP-NORTHEAST-1)で発生した AWS Direct Connect サービスの中断に関する追加情報を提供いたします。

 

(事象)

日本時間2021年9月2日午前7時30分以降、Direct Connect をご利用中のお客様が、東京リージョンに向かうトラフィックについて、断続的な接続の問題とパケットロスの増加が発生しました。

この事象は、「Direct Connect ロケーション」から、「顧客のVirtual Private Cloud(VPC)が存在する東京リージョンに属するデータセンターネットワーク」へのパスの中にある一部のネットワークレイヤーで、あるネットワークデバイスに障害が発生したことが原因です。

お客様は午後12時30分に復旧を観測しはじめ、午後1時42分に接続の問題は完全に解決されました。

AZ間のトラフィック、リージョンへのインターネット接続、AWS Virtual Private Network (VPN) 接続 (一部のお客様が Direct Connect へのバックアップとして使用) など、他のすべてのネットワーク接続は影響を受けませんでした。

他の AWS リージョンへの Direct Connect トラフィックも影響を受けませんでした。

 

(経緯と暫定対応)

2021年9月2日午前7時30分に、AWSのエンジニアは、お客様が東京リージョンに接続する Direct Connect のパケットロスの増加について内部アラームを検知しました。

このアラームにより、Direct Connect ネットワークの単一レイヤー内にあるいくつかのデバイスの障害によって、事象が引き起こされたことを特定しました。

これらのデバイスはトラフィックを正しく転送していませんでした。

ですが、障害が発生したネットワークデバイスは、機器障害時に自動削除を行う通常のプロセスを通じてネットワークから除外されませんでした。

その代わりにこの自動プロセスは、通常よりもデバイスの故障率が高いことを検知し、エンジニアに調査し修復措置を講じるよう警告しました。

AWSのエンジニアは、この警告を受けたとき、このレイヤに十分な冗長性があると判断しました。正常なデバイスでトラフィックを処理できるようにするために、問題のあるデバイスを手動でサービスから除外しました。

並行して、チームは故障の原因を調査していました。

問題のあるデバイスを除外することで一時的に修復しましたが、その後いくつかの他のネットワークデバイスでも同じ障害が発生しました。

その結果、Direct Connectを利用中のお客様のネットワークに輻輳、接続障害、またはパケットロスの増加が発生しました。

AWSのエンジニアは、故障したデバイスをリセットして徐々にサービスに戻すなど、いくつかの緩和を試みました。

しかし、障害は継続しました。

AWSのエンジニアは適切な機器能力を維持し、顧客への影響を完全に軽減することができませんでした。

AWSのエンジニアは障害を引き起こした可能性のある最近の変更対応を確認しました。

午後12時までに、AWSのエンジニアはこの障害の原因は以下の2つが起因しているのではないかと考えました。

①頻度の低いネットワークコンバージェンスイベント(経路情報の交換イベント)

②ファイバー切断に対するネットワークの反応時間を最適化するために導入された、新しいプロトコル

この新しいプロトコルは何ヶ月も前に導入されそれ以来問題なく運用されていました。

AWSのエンジニアは、結論として、今回の障害がDirect Connectネットワークのあるレイヤーを構成するネットワークデバイス上において、新しいプロトコルと新しいトラフィックパターンが相互作用して発生したと考えました。

AWSのエンジニアは、問題が発生している単一のAZでこの新しいプロトコルを無効化しました。

結果として障害の状況は解消し、持続的なリカバリーが確立したことを確認しました。

並行して、東京リージョン全体に展開するための変更対応を準備し、実施しました。

お客様は午後12時30分よりアプリケーションの復旧を確認し始めました。

そして、午後1時42 分に影響を受けたネットワークデバイスが安定した動作状態に復元され、Direct Connect サービスが通常の動作に戻りました。

 

(根本原因と対応)

新しいプロトコルを無効にすることでこの事象は解決しましたが、エンジニアリングチームは根本原因を特定するために引き続き取り組んできました。

この事象は、ネットワークデバイスのオペレーティングシステム内の潜在的な問題によって引き起こされたことを確認しました。

このバージョンのオペレーティングシステムでは、ネットワークのフェールオーバー時間を改善するために使用される新しいプロトコルが有効になります。

新しいオペレーティングシステムとプロトコルは、以前から実稼働環境で正常に実行されています。

AWSは、オペレーティングシステムを変更し新しいプロトコルを AWSネットワークに導入するときには、制御され、自動化され、試験され、計測された一連の手順を実施しています。

この手順は、専用の試験環境での一連のストレステストから始まり、ネットワークデバイスの有効パケットと無効パケット(不正な形式のパケットなど)の両方に対する回復力を検証します。

試験環境でのテストで特定された異常は、新しいコードが本番環境にリリースされる前に調査し根本原因を特定し修復します。

しかし、この包括的なテストでも試験環境ですべてのトラフィックとパケットの順列をテストすることはできません。

したがって、AWS はネットワークデバイスのオペレーティングシステムの変更を、段階的かつ制御された方法で本番環境にリリースするデプロイ手順を使用します。

このデプロイ手順では、アップグレードされたデバイスが実稼働トラフィックを処理を行い始めたとしても、アップグレードされていないデバイスに容易に切り戻すことができるようにします。これを前提に、個々のデバイスをアップグレードしていきます。

段階的に本番環境にデプロイしていく際は、アップグレードされたデバイスは、パフォーマンスの問題や機能エラーについて、広範囲に監視されます。

この段階的にアップグレードしていくデプロイ手順は何度も正常に使用されており、今回の最新のデバイスオペレーティングシステムのアップグレードでも遵守されました。

新しいプロトコルとオペレーティングシステムは、2021年1 月に初めて実稼働環境に導入されました。

過去8か月間にわたって、この新しいプロトコルとオペレーティングシステムは、すべての AWS リージョンで徐々に実稼働環境にリリースされ、潜在的な問題を示すことなく Direct Connect のサービスを提供してきました。

そして、過去数日間で、AWSのエンジニアはネットワークオペレーティングシステムの欠陥を特定し、問題を引き起こす非常に特殊なパケット属性とコンテンツのセットが必要であると判断しました。

これらの条件は非常に特殊で稀であるものの、このシグニチャに一致するある顧客のトラフィックによってこのイベントが発生しました。

悪意のある振る舞いがあったとは考えておりません。

我々は、AWS 東京リージョンでこの問題が発生した新しいプロトコルを無効にしました。

また、この変更を他のすべての AWS リージョンに慎重に適用するために、お客様に影響が出る前にこの問題を検出して修復するための拡張方法も開発しました。

この問題によるお客様へのさらなる影響はないと確信しています。

 

(最後に)

AWS のサービスが日本のお客様と多くのビジネスにとって重要であるかを理解しており、今回の事象による影響を心からお詫び申し上げます。

AWS は、高い可用性でサービスを運営してきた長年の実績があり、お客様の信頼を維持し、お客様とビジネスに必要な可用性を達成するために全力を尽くします。

 

※意訳は以上です

--------------------------

 

ちょっと、感想

よく「ハードウェアの問題」と言いますけど、この文書のとおり完全にソフトウェアの問題ですよね。

ハードウェアの問題と言って、ばっちりハードウェアの問題なんて最近だとなかなか起きません。昔は、熱の問題で電源が停止したり、ネットワーク機器であればポートが使えなくなったりといろいろ体験したことはありますが、最近のハードウェアはいたって優秀な印象です。

一方で、ハードウェアが高機能化しました。高機能化の理由は、その中にあるソフトウェアが進化したことに尽きます。

ソフトウェアですから、不具合の一つや二つ抱えていても不思議ではなく、かつ、冗長構成にしていても、両方の機器に同じソフトウェアを入れるので、両方等も問題が起きちゃう、そんなロジックです。

もし神経質に設計するなら、違うベンダーで別ルートを作るという方法もありますが、それだと管理も2倍大変になります。

悩ましい話だな、と今回の話を見ても思いました。一方で、よくこんな短時間で原因までたどり着き切り戻したもんだな、と思いました。