/* */

製品でチャレンジしすぎて失敗

田中(゜p゜)は長年ITインフラエンジニア/PM/ITコンサル？をやってきましたが、当然失敗したこともあります。

インターネットのサイトには輝かしい成功の記録が数多くありますが、失敗事例はとても少ないです。

このサイトなんかは業界問わず失敗の事例公開してて、とても参考になります。

失敗の例を共有して、次は他の人も失敗しないようにすることが大切なのかな、と思うので、ここに田中(゜p゜)の事例をサマリで記載します。

案件内容

  • タイトル: 某商社インターネットセキュリティ更改案件
  • 案件規模： 5年1億8千万 メンバー5人 エンドユーザー12000人
  • 田中(゜p゜)のポジション： PM

経緯

田中(゜p゜)の初めての炎上案件。
当時、プロキシサーバとして安全牌だったのはBlueCoatで、田中(゜p゜)の実績も複数件あった。

が、ちょうど自社でVMwareの基盤をサービスとして展開しはじめて、それを使えとのプレッシャーも強く、メーカーの値引きも大きく、国内であまり実績のないWebsenseのLinuxソフトウェア製品を選択。

失敗の内容

プロキシに対する負荷テスト、2週間の情シス部門に対するプレテストは無事に終わったものの、本番サービスイン後の1時間後に本番機2台が大きくスローダウン。エンドユーザからクレーム多発。切り戻し。

原因

ソフトウェアのバグにより、特定のユーザの、特定のアクセスパターンにより、プロセスのフリーズ/リセットが発生。フリーズの蓄積により、メモリが食いつぶされて、スローダウンに至った。

負荷テストの単純なアクセスパターン、情報システム課のテスト時には含まれていないアクセスパターンだった。

その後の調査で、切り戻したBlueCoatでは同様の事象は、設定により回避していたことが判明したが、Websenseに同様の設定はなく、ソフトウェアの回収を待たなければならなかった。

結果

3ヶ月サービスインを延期し、その間にバグ回収と運用での回避を模索。

3ヶ月後、サービスインするものの、パフォーマンスは出ず、当初2台＋検証機1台で運用する予定が、3台とも本番機として投入することになり、運用にも多大な迷惑をかけた。

また、切替前は通信できていたのに、切替後に通信できなくなったケースが多発し、その度にプロキシに例外設定が必要だった。

その件数は数十件に達し、当初は始末書を書いていたが、お客様担当者から、個別のクレームについては不要との、不名誉な緩和を頂いた。

リカバリの間の田中(゜p゜)の月稼働時間は400〜500時間にも達した。

反省点

トラフィックパターンを調査していったところ、Webサーバ側にRFCの必須、推奨要件を満たしていない通信が多数あり、WebSenseは、RFCに則っていない通信については、エラーを返すか、スタックを起こしていた。

逆に、BlueCoatはそうしたトラフィックに対して上手いことごまかして通信を継続していたように見える。

過去の蓄積が、イレギュラーなものに対しての柔軟性として製品に反映された結果、製品コストが高くなっているのだと痛感した。

2020/09/12