PagerDutyのDoug Barth氏が，特別な自動化作業を前もって用意することなくシステムの復元性テストを開始するという，同社で実施したアプローチについて，DevOps Days Londonで講演した。目標としたのは障害発生点の早期発見と，１週間に１時間の時間枠を設けて，その対処方法についてオープンに議論することだ。
Netflixで有名なsimian armyのようなカバレッジで障害テストを自動化することは，PagerDutyのマルチクラウド環境では実現不可能だ。また，社内の自動ツールに投資したとしても，初期結果を得るまでには時間を要する。そこで同社では，"Failure Friday" と名付けた手動の障害テストアプローチを採用することにした。毎週金曜日の1時間を使って一連の "アタック" (障害を引き起こす) を実行し，”犠牲者” (テスト対象のシステム)の反応をチェックするのだ。
アタックとアタックの間，システムは通常の動作状態に戻される。大きな障害が発生した (例えば障害発生後，犠牲者システムへ送られたリクエストが，他のサービスインスタンスによって処理されなくなったような) 場合，アタックは中止される。この時はセッションを停止して，システムを一旦，手動で回復させる。その上で次の金曜日に，恒久的な対策をテストするのだ。そういったことがなければ，アタックは1時間，セッションが終了するまで継続される。
アタックの方法は，Cassandraデータベースインスタンスの停止やサーバインスタンスの再起動といった簡単な障害シミュレーションから始まり，より複雑な，ネットワーク分離 (IPテーブルの設定ミスによりドロップしたパケットの特定ポートへの転送) やノードの能力低下 (netemのネットワークエミュレーションを使用) のシミュレーションにまで及ぶ。
システムの問題解決に加えて，障害の処理とテストの必要性に関する全般的な意識向上などが，期待される効果として挙げられる。しかしそれよりも氏が強調したのは，実際に体験するまでの間に陳腐化したり不正確なものになるような，単なる理論的知識ではなく，故意に発生させた障害を経験し理解した結果として，新たなオンコール対応技術者(開発あるいは運用において)の数的拡大が可能になるという，副次的な効果の方だ。その他にも期待していなかった効果として，シミュレーションの難しいコンポーネント障害の所在が明らかになったことがある。これが要因となってアーキテクチャが変更され，システム全体のテスト性を向上することができた。
実務的組織の観点から氏は，実施記録と活動時間，発見項目と障害記録に加えて，ダッシュボードと測定基準を公開することの重要性にも言及した。さらに氏は，監視システムが所定の動作をしていることの確認のため，セッション中も警告を停止しないことを推奨した。ただし，故意に起こした障害がアラームエスカレーションされるのを避けるため，アタックセッションの実施をすべての人々に周知することも付け加えている。