1 ポイント 投稿者 GN⁺ 2024-09-14 | 1件のコメント | WhatsAppで共有
  • 2024年7月の大規模障害以前から、元従業員たちは厳しいスケジュールと過剰な業務量、増え続ける技術的問題を経営陣に伝えてきたと述べている
  • インタビューに応じた元従業員24人の多くは、経営幹部が品質より速度を優先し、一部の従業員は十分な訓練なしにコーディングや運用業務を担っていたとみている
  • CrowdStrikeは元従業員らの説明の多くを否定し、情報源は「会社方針に明確に違反して解雇された、一部の不満を持つ元従業員たち」だと反論した
  • 7月のFalcon Sensorアップデートの不具合は850万台のコンピューターを停止させ、Fortune 500企業に最大54億ドルの損害をもたらし、CrowdStrikeは当四半期に見込んでいた約6,000万ドルの契約を取り逃した
  • 長期的な品質・運用上の問題と7月の障害との直接的な関連性は確認されていないが、その後CrowdStrikeは売上・利益見通しの下方修正、議会証言、訴訟圧力に直面している

障害前から蓄積していた品質への懸念

  • CrowdStrikeの元ソフトウェアエンジニアらは、7月の大規模障害より1年以上前から厳しい納期、過剰な業務量、増え続ける技術的問題を上層部に伝えていたと述べている
  • 元従業員らによれば、こうした問題提起は会議、メール、退職面談で繰り返し行われていた
  • 元シニア・ユーザー・エクスペリエンス・デザイナーのJeff Gardnerは、「速度が最も重要だった」とし、品質管理はプロセスにも会話にも含まれていなかったと語った
  • ある元シニアマネージャーは、複数の会議で従業員たちが「支えきれない製品」をリリースすれば、顧客を「失敗」させることになりかねないと警告していたと明かした

食い違う元従業員の証言と会社側の反論

  • Semaforの取材に応じた元従業員は計24人
    • 10人は解雇または人員削減の対象になったと述べた
    • 14人は自発的に退職したと述べた
    • 1人は2024年夏まで同社に在籍していた
  • 元従業員3人は、ほかの従業員たちの説明に同意していない
    • 2023年に退職したJoey Victorinoは、CrowdStrikeは「行うすべてのことに非常に綿密だった」と評価した
  • 会社は報道内容の多くを否定している
    • 情報が「会社方針に明確に違反して解雇された、一部の不満を持つ元従業員たち」から出たものだと述べた
    • 製品のレジリエンスを確保するため厳格なテストと品質管理を行っており、これに反する説明は全面的に否定するとした

急成長の後に起きた7月の障害

  • CrowdStrikeは2011年設立で、2013年にFalconアンチウイルス・パッケージを投入してサイバーセキュリティ業界の主要企業へと成長した
  • 2019年の上場後、従業員数を数千人規模で増やし、2024会計年度末までに売上は1,000%以上増加した
  • 2024年7月の誤ったソフトウェアアップデートは、史上最大級のIT障害になり得る出来事につながった
    • 850万台のコンピューターが停止
    • Fortune 500企業の損害は最大54億ドルに達する可能性
    • 航空旅客は空港に足止めされ、オンラインバンキングへのアクセスが遮断され、緊急通報センターがオフラインになった
  • CFOのBurt Podbereは8月28日の決算発表で、7月31日終了四半期に締結を見込んでいた約6,000万ドルの契約を取り逃したと述べた
  • CEOのGeorge Kurtzは、7月19日の出来事の規模を忘れず、二度とこのようなことが起きないようにすると述べた

テスト・顧客データ・LogScaleの事例

  • 一部の元従業員は、製品リリースの速度を合わせる過程でソフトウェア品質の点検が急がされることがあったと述べた
  • 2019年から2023年まで勤務したPreston Segoは、十分なテストを行うよう人々を説得するのが難しい時があったと語った
    • 彼の業務は、コード変更が顧客に展開される前に、ユーザー体験開発者によるテストがバグを適切に知らせるかを確認することだった
    • Segoは、社内Slackで復帰出社方針を批判した後、2023年2月に「insider threat」として解雇されたと述べた
    • CrowdStrikeは個別の人事案件については議論しないとした
  • 専門サービス部門では、ある顧客の非公開情報が別の顧客フォルダに3回誤ってアップロードされかけた事例があった
    • CrowdStrikeは当該事案を認め、原因は手動のデータ入力ミスだったと述べた
    • データはホスト名、IPアドレス、ドメイン名といった基本情報だったと説明した
    • 現在は顧客の非公開データが誤送信されないようチェックを実施しているとした
  • 複数の元従業員は、Falcon LogScaleでも問題があったと述べた
    • ある1人は、誤ったアップデートにより潜在的な悪意ある活動を知らせるリアルタイムアラートが少なくとも2回一時停止したと振り返った
    • 一部のエンジニアは社内会議で、これを厳しいスケジュールのせいだと見ていたと述べた
    • CrowdStrikeは、顧客がアラートを受け取れなかった「bad update」は把握していないとして、この事例を否定した
    • 会社は、LogScaleは顧客に潜在的なデータ侵害を「リアルタイム」で通知するよう設計されたサービスではないと述べた

Falcon OverWatch Cloud Threat Huntingのリリース論争

  • ある元従業員は、2022年にリリースされたFalcon OverWatch Cloud Threat Huntingは急いで投入されたと述べた
  • このサービスは、CrowdStrikeのセキュリティ専門家がAmazon Web Servicesのような顧客クラウド環境で侵害を示唆し得る不審な挙動を探すものだ
  • プロジェクトに参加した元シニアマネージャーは、通常なら1年かかる仕事をエンジニアと脅威ハンターに2カ月で任せたと述べた
  • 彼は、リリース時点で脅威ハンターたちには顧客クラウドシステムを完全に監視するために必要な社内ツールが不足しており、リリースから約1年後の昨夏まで既存のセキュリティシステムのアラートに対応していたと述べた
  • 同じ元シニアマネージャーは、ノートPCやデスクトップのような顧客コンピューターシステムを監視する訓練を受けた従業員をクラウド脅威検知に投入しながら、新たな教育を義務化しなかったと述べた
  • CrowdStrikeは、新たな「cloud threat hunters」チームを採用する代わりに既存エンジニアを活用したことを認めた
    • 新しいサービスだったため、経験ある「cloud threat hunters」を見つけられず、CrowdStrikeが開発するまで存在しなかった分野について特定の訓練を受けた人材を採用するのは不可能だったと述べた
    • 新たな教育を義務化はしなかったが、希望する従業員には提供していたと述べた
    • 従業員は職務に適した教育を定期的に受けていると付け加えた
  • SANS Instituteは、CrowdStrikeのサービス開始2年前に当たる2020年から、クラウドセキュリティの教育課程講演を提供してきた
  • CrowdStrikeは、OverWatchサービスは常に意図通りに機能しており、プロジェクトを急がせたとか、脅威ハンターに必要なツールが不足していたという説明を否定した

古いコードと増えた業務量

  • Segoは、プロジェクトを進めるために暫定的に書かれたコードが後で改善されないことが多かったと述べた
  • ある元シニアエンジニアは、古いコードを修正する時間を求めて20回以上要請したが受け入れられなかったと明かした
  • CrowdStrikeは、コーディングは反復的なプロセスであり、実際の製品体験を踏まえてコードをデプロイし継続的に改善することはソフトウェア業界では一般的だと反論した
  • 元従業員らは、古いコードを改善できなかった理由の1つとして業務量の増加を挙げた
    • 一部は人員削減と組織再編の後でさらに多くの仕事を担うようになったと述べた
    • CrowdStrikeはレイオフへの言及を拒み、従業員数は毎年着実に増えていたと述べた
    • R&D費用は2022会計年度の3億7,130万ドルから2024会計年度の7億6,850万ドルへ増加し、その大半は従業員数の増加によるものだと説明した
  • 会社は、チームからのさまざまなフィードバックを受け取り、評価・反映し、高い成果を求める文化の維持に注力していると述べた
  • さらに、直近4年間にわたりFortune 100 Best Companies to Work Forに選ばれた点も付け加えた

障害後のコストと後続手続き

  • CrowdStrikeは7月の障害原因をFalcon Sensorアップデートの不具合に求めている
  • この出来事で同社の株式市場価値は210億ドル超減少した
  • 複数の訴訟が続き、Delta Airlinesは数千便の欠航後の損失を5億5,000万ドルと見積もり、訴訟の可能性を示唆した
  • 上級副社長のAdam Meyersは2024年9月中に議会で証言する予定だ
  • CrowdStrike PresidentのMichael Sentonasは8月のハッカーコンベンションで「Most Epic Fail」賞を受け取り、ひどく間違えた時にそれを認めることは非常に重要だと語った
  • 元従業員らが語った長期的問題と7月の障害との関連性は、現時点では確認されていない

1件のコメント

 
GN⁺ 2024-09-14
Hacker Newsの意見
  • 「スピードが最優先で、品質管理は私たちのプロセスや会話の一部ではなかった」といった具合に、不満を持つ元社員に頼って作られた記事は、GrubHubの謝罪ギフトカード程度の価値しかなさそうに見える
    CrowdStrikeを好意的に見ているわけではないが、恨みがあって注目される機会があれば、誰でも何とでも言える。しかもこの人はデザイナーで、品質管理に直接関わっていたわけでもないはず
    記事にも、元社員24人のうち10人は解雇・レイオフ、14人は自主退職で、3人は他の証言に同意しなかったとある。Joey VictorinoはCrowdStrikeが「すべてのことに細心の注意を払っていた」と述べているので、結局確かなことはほとんどない

    • 「確かなことがない」と言うには、史上最大のIT障害が起きており、事後分析でも検証チェックが不足していたと示されていた
      段階的ロールアウトもなく、いきなり世界中の本番環境に押し込まれ、新しいコードが実際にインストール・実行されるラボもなかった。煙が見えていて、火が出たという証言も複数あるので、そうした文脈で見ることができる
    • CrowdStrikeのような会社があれほどの甚大な大事故を起こした後で、元社員たちに「不満を持つ人々」というレッテルを貼る資格はあまりないように見える
      むしろそういう社員のほうが内部状況を率直に語る可能性が高く、品質保証・品質管理部門でなくても雰囲気は分かる。会社に同調する人より、そうした情報のほうが信頼できる
    • 私たちが持っているのは、Semaforがインタビューした人々は信頼に足るもので、興味深い点があり、互いに、または他の証拠とおおむね整合していると判断した、という報道である
      Semaforが仕事ができない、あるいは悪意があると主張することはできるが、引用された段落自体で反対証拠まで併せて示している点を見ると、簡単な主張ではない
      会社の元社員1人から聞いた話なら個人的事情かもしれないが、複数の人が同じ不満を述べているなら、はるかに真剣に受け止めるべきだ
    • これはオンラインレビューに似ている。肯定的・否定的なレビューだけを選び、残りを隠せば役に立たないが、見つけたレビューをすべて報告するなら依然として有用だ
      不満を持つ人のほうがレビューを残す可能性が高く、CrowdStrikeを去った人も不満を持っていた可能性が高い。偏ったデータではあるが、それでも役に立つデータだ
    • 設計が品質管理に関与していないなら、品質管理をうまくやれているとは言えない。設計が開発プロセスとつながっておらず品質管理を理解していないなら、設計もきちんとできていない
  • ここのコメントがあまりにも簡単に片付けているようで驚いた。エンジニアを含む元社員たちが、元の会社の危険な開発文化が世界規模の大障害や過去の障害に寄与したと述べている
    こうした証言は信頼に足る、少なくとも有益な情報として見るべきなのに、多くの人は「品質管理は私たちのプロセスの一部ではなかった」と言ったUXデザイナーだけを攻撃しているように見える
    おそらく「リリース速度がすべて」という文、つまり「素早く動いて壊せ」に、多くの人が自分を投影しているのだろう。コードをデプロイする快感、火消し、インパクトを生むこと、そして後始末を次のエンジニアやマネージャーに押し付ける文化に慣れているからだ
    ゼロ金利時代の視点では、こうしたプロセスの失敗はバグではなく機能のように見えたのかもしれない。「品質」を重視することも、顧客の金で楽しく働くのを妨げる面倒な障壁のように見えたのだろう

    • これはゲームではない。通常なら同意しただろうが、低レベルのカーネルドライバなら話は別で、セキュリティ企業なのでさらに深刻だ
      以前、ある顧客がカーネルドライバベースのカスタム高セキュリティソリューションを注文したことがあり、オフラインのコンピュータで重要なデータベースを動かしていて、すべてのシステムコールを追跡し、データ変更があれば正確な変更内容を警告・記録する必要があった。バックアップも絶対に外へ出てはならず、現地インストール前にWindowsのntdllフック有無を確認するような安全手順も求められた。例外、停止、デッドロックは許されず、システムコールを1つでも取りこぼせば大惨事だった
      そのためドライバコードが変わるたびに、異なるハードウェアのオフィスPC 7台で決められた手順に沿って再テストし、リリース前の最終テストはさらに広範囲だった
      この基準で見ると、CrowdStrikeはほとんど完全な素人に近い。セキュリティコミュニティへの貢献もなく、研究レベルもジュニアのセキュリティ研究者程度に見える。露骨に誇張したり拙速な結論を出したりする姿勢も、コミュニティでは好意的に見られない
      KasperskyやCheck Pointのような本物の専門企業を見るべきだ。検証済みの最高水準のセキュリティソリューションを作っただけでなく、ゼロデイを見つけて悪用される前に報告するなど、価値ある研究を無償でコミュニティに提供してきた。CrowdStrikeは批判されて当然だ
    • 比喩的な火消しを楽しむ人がいるのか?そうした手戻りはかなりフラストレーションがたまるものに感じる
    • 元品質保証エンジニアとして、品質は自己利益を追う人々の前に置かれた面倒な障壁として扱われることを確認できる。表向きには、顧客の金で楽しむのを妨げるものだというように言い換えられることもある
      何年にもわたって繰り返し見てきた組織再編戦略の中で最も印象に残っているのは、「エンジニア全員を各ドメインで即座に交換可能な人材として訓練する」というものだった。完全に足踏み状態だ
  • 重要なソフトウェアインフラは、重要な物理インフラと同じように規制すべきだ。建物や橋を作る人たちが「勝手に正しくやるだろう」と信じるのではなく、規制と検査を義務付けるのと同じようにすべきだ
    ソフトウェアが止まったときに世界中で何百万人もが足止めされるなら、それは重要インフラである。今回は普通の「事故」だったが、今後、戦争状況で脅威アクターがシステムを崩壊させようとすれば、さらに深刻になり得る

    • 問題のソフトウェアが、すでに規制と検査がシステム管理者の常識より優先される企業に主にインストールされていた点を見たのか気になる。答えが単に同じ規制の追加だと確信できるのか?
    • そもそもそれらの企業がCrowdStrikeを動かしていた理由が規制だった
    • 「業界を規制すれば米国は中国に負ける」とか「規制は米国の競争優位を殺す」という反応を何度も聞いたが、本当にうんざりする
      安全に関わる重要な領域なら、他のものより厳しく見るべきで、営利企業の自主規制的な品質保証プロセスに任せるべきではない。大きなボタンを押す前に、より多くのレビューが必要だ
      付け加えると、引用符内の文は私の言葉ではなく、規制の話を持ち出したときに他の人たちから聞いた反論だ
    • 何事もそうだが、安く、速く、良くのうち2つだけを選ぶ法則が当てはまる
      ソフトウェアはほぼ常に安く速く作られる。NASAでさえ、ソフトウェアのミスでロケットが飛行中に爆発することがある
  • 昨日の朝、知人が亡くなり、葬儀は来週に決まったという知らせを聞いた。
    その人は1か月以上入院していて、家に戻って数日後に脳卒中を起こした。
    ただ、本来は重要な手術を受ける予定だったのに、CrowdStrikeの障害のせいで延期されたことを思い出した。再調整されて手術が行われるまでに数週間かかった。
    その日に手術を受けていて、病状や今後へのストレスの中でさらに数週間入院せずに済んでいたら、結果は違っていたのだろうかと考え続けてしまう。

    • こういう話を残してくれてありがとう。共有してくれてよかった。これは分散した被害の一例だ。
      今回の件で数百万件生じたであろう被害の一つだが、金額に換算されないので実際には「計算」されない。
      例えば3歳の子どもの膝を蹴って一生残る障害を負わせれば、当然ながら怪物と呼ばれるだろう。だが、米国手話を学校から締め出す教育改革を支持し、聴覚障害のある子どもが発達期に言語を持たずに育つようにしてしまった場合、その行為の累積的な規模や被害を表す言葉すらまともにない。
      私たちは分散した被害をうまく扱えない。大きな理由は、それによって生じる具体的な被害の全体像を見ていないし、見ることもできないからだ。
    • CrowdStrikeを擁護するつもりはないが、マイナス面だけを見るのは少し不公平だ。その病院がワクチンソフトウェアを買わずにランサムウェアにやられていたらどうだっただろうか?
  • エンジニアリングプロセスの専門家として引用されている人がシニアUXデザイナーというのは疑問だ。カーネルパッチの配布プロセスにそれほど近かったとは思えない。

    • 直接近かった可能性は低いが、それでも会社全体の文化を示しており、私たちが知っているカーネルエンジニアリング文化とも一致している。限定的なテスト、レビューの欠如、一般的な安全装置の未使用といったものだ。
  • CrowdStrikeの品質管理を正当化するつもりはないが、私が経験してきた複数のソフトウェア開発現場でも、品質管理が抜け落ちているケースはかなり多かった。
    記事を読むと、すべてのソフトウェアプロジェクトがきちんとテストされているように感じるかもしれないが、私の経験では大半は急いでリリースされている。

    • いくつもの数兆ドル規模のソフトウェア企業で働いたが、意図的に専任の品質保証組織を置いていなかった。すべては素早く動くことに焦点が当てられていた。
      エンターテインメントソフトウェアや重要度の低い業務ソフトウェアなら問題ないかもしれないが、重要なソフトウェアでは非常に悪い考えだ。残念ながら、「素早く動こう」という姿勢が、本来あってはならない場所にまで広がってしまった。
    • このテーマに関する多くの議論は、理想的なテストとデプロイの慣行を前提に語られてきた。シリコンバレーや投資銀行は違うのかもしれないが、私が働く通信会社のような企業はその理想からほど遠い。
      業界は、少数の有能な人々がどうにかシステムを回している一方で、それ以外では衝撃的な技術的無能さが露呈する場所のように見える。経営陣は機会があるたびに品質より短期的なコスト削減を優先し、その結果、ひどい技術的負債と、意欲を失った過労の人員が積み上がる。品質問題を口にすると不利益を受けるので、結局人々は品質を気にしなくなる。
  • 元従業員の一部が不満を抱き、CrowdStrikeを悪く見せるように語ることはあり得る。どんな会社でもそういうことは起きる。
    だがCrowdStrikeはいま信頼度がゼロだ。彼らの言うことは一言も信じない。

    • Boeingのような会社では、満足している従業員のリストのほうが短いかもしれない。
  • CrowdStrikeについて知られていることはすべて、Knight Capitalを思い起こさせる。小さな文化的問題が完全な機能不全へと転がり、最終的には会社を終わらせるバグにつながる流れだ。

    • Knight Capitalは1分あたり1,000万ドルを失っていた。
      水曜朝の株式市場の混乱を引き起こした取引上の問題で、すでにそれだけのコストがかかっており、Knight Capital Groupはコンピュータの不具合により誤って購入した株式をすべて売却し、4億4,000万ドルを失ったと発表した。
      「不具合」だなんて……
      https://en.wikipedia.org/wiki/Therac-25
  • 以前の会社で、一部の顧客と賠償責任保険会社がコンプライアンス上の理由でCrowdStrikeの導入を強く求めてきた。特にBCGはCrowdStrikeの使用を要求していた。
    CrowdStrikeを使わないよう説得するのは本当に厳しい戦いだった。最終的には成功したが、複数のステークホルダーを説得するために多くの会議と時間が必要だった。多くの人はそのまま折れて導入したと思う。

    • 結局、別のEDRソリューションを使ったのか、それともそもそも配布しないよう説得したのか気になる。
  • 組織にCrowdStrikeエージェントを配布するチームで働いたことがあるが、最大の問題の一つは、デーモンが膨大な量のログを吐き出すにもかかわらず、それを止めたり減らしたりする設定がなかったことだった。