それは彼らの耐性次第だね。人はよく一つのバスケットに全ての卵を入れちゃうから。

90年代後半、ファームウェア開発の仕事をしてた製造会社で働いてたんだけど、まだ全部紙でやってたんだよね。彼らはOracleの上に構築した自社製のERPシステムにうまく移行したんだけど、大きな祝賀会があってみんな喜んでた。6ヶ月後、誰かがフォークリフトで機械室の壁を突き破ってUPSに突っ込んで火事になって、Oracleノードを含む3つのラックが壊れちゃった。結局、誰もそのシステムを本当に信頼してなくて、裏で紙を使ってたんだよね。6年後に辞めるときも、まだ紙でやっててExcelで報告してた。これがうまくいってて、フォークリフトに対してはかなり安全なんだよね。

90年代後半、2000年代初頭にデンマークの国防省が新しい調達システム、DeMarsをSAPで構築することに決めたんだ。調達部門で働いてた軍曹を知ってるんだけど、彼は立ち上げの数ヶ月前に自分が担当してたものを異常に大量に購入してた。結局、詐欺の疑いで取り調べを受けることになったんだ。彼はDeMarsの立ち上げに信頼を置いてなくて、在庫が切れないようにしたかったって説明したんだ。すべては記録されてて、もし誰かが彼が詐欺を犯してると思うなら、完全な在庫調査をするのも自由だって言ってた。DeMarsが立ち上がったけど、調達は基本的に1年間止まっちゃった。友達が担当してたアイテムだけが、立ち上げ/展開プロセスの間ずっと在庫に残ってたんだ。

一方で、製造業の周りにしっかりとしたIT自動化が確立されていて、人々が自動化前の製造に訓練されていない場合、手動に戻るのはかなり難しいよね。おそらく、注文やワークフローの複雑さにも依存すると思う。

Excelは多くの普通のオフィスワーカーが理解できて修正できるっていう利点があるよね。ほとんどのITインフラにその機能が必要だっていうのがないのはちょっと驚きだな。それがあれば、もっと使いやすくなるのに。

製造業で働いていると、ドローンの部品を作っているかもしれないけど、どの側のために作っているのかわからないこともあるよね。信頼できそうな会社を通じて個々の部品を買えるから。命を救う手術用の部品を作っている可能性もあるし。でも、全体的には、誰も捨てたくないような実用的な家具を作りたいな。人を守りたいと思う人を応援するけど、戦争は本当にひどいよ。

ソフトウェアがなければ、ドローンは役に立たないよね。もし在庫を完全に把握していれば、手動で動かすクアドコプターを組み立てることはできるかもしれないけど、3Dプリントで部品を作ったり、安定した飛行や自律運用、監視などの高度な用途に対応したドローンを生産することはできない。リモートコントロールも多分無理だね。

可能性はあるね。でも、地下室でレンチを持ったチンピラがいて、システム管理者がSSHキーや2FAを渡しちゃった可能性もある。

トマト、トマトだね。一方では戦争があるって言ってるから、その理由は無意味だと思う。軍に直接雇われてない人をリクルートする方が簡単だから、こういう区別があるんじゃないかな。

外国の情報機関については何も言ってないね。

ウクライナとロシアの話をしてるけど、もう何年も戦争が続いてるんだよね。ここで疑いの余地なんていらないよ。

外国の情報機関がボタンを押させたから、ロシアに対する直接的なサイバー戦争ではないけど、その一方でロシアの情報機関はすでにNATO諸国を直接攻撃してるし、ほとんど本当の否定はできないよね。

ウクライナの軍事情報機関。

いや、明らかにウクライナって書いてあるじゃん。外国の情報機関が関与してた証拠はあるの？

外国の情報機関がボタンを押させたから、ロシアに対する直接的なサイバー戦争ではないってこと？どこの外国の情報機関？それに、誰からも常に攻撃が来てると思わないなら、現実世界に準備ができてないよ。

スティーブ・ギブソンが数年前に言ってたのを覚えてるけど、アメリカがロシアの鉄道インフラをサイバー攻撃しない理由は、攻撃の痕跡を「隠せないから」なんだって。これは本当の理由じゃないよ。この説明は本当の理由を隠してる。ロシアはアメリカにとって価値のある地政学的パートナーだから。アメリカの政権が誰であれ、全ての大統領がロシアとの取引や接触を試みてきた。アメリカにとって、ロシアがこの戦争に負けたり、内部の不安定さや20近くの国家に分裂したりすることには価値がない。アメリカは、ロシアが今のように血や苦しみ、政権の生存のための何十万もの死を伴っている方が得をする。実際、アメリカはロシアで内部問題を引き起こすほど強く押すことを恐れている。そしてロシアの支配層もそれを知ってる。

もう一つの理由は、ロシアの鉄道が依存しているITインフラがあまりないことだと思う。人を運ぶためのチケット販売システムはあるけど、大部分は貨物列車だし、それを簡単に妨害する方法があったら、ウクライナはとっくにやってるだろうね。ロシア軍は鉄道を使った補給に大きく依存してるから。

彼らがそれに気づいて、ドローンを再フラッシュするのにどれくらいかかったと思う？

毎日何百ものドローンが市民に降り注いでる状況じゃ、生産を無効にすることが、将来的にうまくいくかもしれないことにこだわるよりも優先度が高いよ。

明らかに、そんなサプライチェーン攻撃のチャンスがあったら、ITインフラを壊すのに加えてそれもやってたはず。とはいえ、ロシア側がファームウェアを既知の良いバージョンに再フラッシュするかもしれないから、日常のドローン運用には影響が出ると思う。

ITにはほとんどすべてにサイクルがあるよね。人々は何かしらのSSOを求めてるし、セキュリティ上も必要だし。今やSSOはほとんどすべての依存関係になってるし、SSOを運営する基盤システムの管理も同様。ネットワークもそうだし、いろんなことがそう。ゼロからのブートストラップは決して簡単じゃないし、常に時間がかかる。完全に冗長で、完全に独立した二次インフラを準備しない限り、これから抜け出す準備はできないと思う。

じゃあ、会社はどうやってこれを対処するの？印刷されたドキュメントからブートストラップできるのか、それともそれも消去される前提なの？

ウェブサイトのせいじゃなくて、あなたの政府やCloudFlareのせいじゃないかな（TLSエラーの根本的な理由でブロックされてるのかもしれないけど、ロシアにいるからってわけじゃないかも）。

リンク先は英語だけど、選択肢について言えば、ロシア連邦の住民はこのウェブサイトのロシア語版のターゲットではなかったと思うよ。ロシアの言語戦争に関する一般的な誤解とは裏腹に、ウクライナでは今でも多くの人がロシア語を話してるし、メディアもロシア語の記事を発表してる。

現代のITのやり方では、災害復旧についてあまり考慮されてないよね。厳格なバックアップ手順を持っている組織でも、復旧テストをすることはほとんどないし。チームが人手不足だから、すぐに何でもかんでも急ごしらえになっちゃう。インフラを簡単に再構築できるように準備するのは、通常のやり方でセットアップするのの倍以上の手間がかかるんだよね。

ドキュメンテーションがめっちゃ大事な理由だよね。ソフトウェアアーキテクチャのレベルでも。数ヶ月後には、今のプロジェクトの決定事項をちゃんと書き留めておきたいな。例えば：

• なんでKyselyを選んだの？Drizzle、Knex、Prisma、TypeORMとか他のORM/SQLツールじゃなくて？
• マイグレーションはどうやってやるつもり？
• DenoかBunを使う理由は？Node.jsにこだわらないのはなぜ？
• プロジェクトを機能ごとのディレクトリ構成にした理由は？コントローラーやモデル、サービスのディレクトリじゃなくて？
• このライブラリをフォークした理由と、更新を続けるためのステップは？変更をアップストリームする予定はある？GitHubに関連するイシューやPRはある？
• AWS、GCP、Azureのどれかでホスティングしてる理由は？ラムダ関数じゃなくて？なんでDocker？
• 他の軽量な選択肢じゃなくて、この特定のKubernetesディストリビューションを選んだ理由は？
• そもそもなんでこのプロジェクトを始めたのか、何を達成したいのか？ だからREADME.mdに# Decisionsセクションを作ったんだ。こうすれば、自分の決定に疑問を持たずに済むし、解決策を比較するために20個のドキュメントタブを開く時間を無駄にしなくて済む。

だからInfra as Codeはめちゃくちゃ重要なんだよね。

うん、似たような経験があるけど、今はnixを使ってて、これが問題を解決してくれるんだ。

一方で、ITを完全に破壊して（クリーンスレートからやり直すために）ビジネスを変革する選択肢がオーバートンウィンドウの中にあった場所で働いたこともあるよ。

とても興味深いけどリスクもあるね（見つかりやすいし、全体の作戦が無効になる）。だから、彼らがやったことは強硬策だけど、最も合理的だったと思う。

うん、工場を閉鎖するよりも、ある意味では役立つように思えるね。ドローンを優しく操作して、リモートコントロールさせたり、発射地点を爆撃させたりすることができれば。