2022/05/07 21:15
sasasin_net
日本語訳だ助かる
2022/05/07 22:13
shodai
“今回のインシデントから前進し、社内プロセスを再評価するにあたり、インシデントを引き起こすのは人ではないという考えを、改めて認識しています。”
2022/05/07 23:51
yasu-osu
障害対応報告の雛形として参考にしたい。
2022/05/08 01:35
mamacake
復旧までの被害クライアントのビジネスプロセスの損害は確かにあった、けれどとても誠実かつ意志のある姿勢だと思う。それが結果としての要因の早期特定にも繋がっていたはず。共有に学びたい。
2022/05/08 07:50
Falky
パブリックアナウンスが遅かったことへの反省も含まれてる。1対1のやりとりを優先した…というのはつまり、非常に重大な障害かつ影響を受けた顧客が特定できていたので、あまり公にしたくない心理が働いたのだろう。
2022/05/08 08:14
tsutaken
内容は小さなミスが大規模障害を引き起こす典型例だけど、他人ごとながら再発防止策が重すぎないのだろうかと心配になった。（遠い外国で同じ仕事をしている人達に思いを馳せつつ）
2022/05/08 08:32
hiroomi
レビューと持ってくるのか。
2022/05/08 09:11
kitayama
エンタープライズ向けサービス提供者は管理体制からなんやらまで、ここまでやる必要があるという分かりやすい事例なのでは。障害対象の企業は大変だったろうけど、現場としては納得できるのでは。
2022/05/08 10:27
yuiseki
“インシデントを引き起こすのは人ではないという考えを、改めて認識しています。むしろ、システムが間違いの発生を許容しているのです。”
2022/05/08 10:50
t_f_m
あとで
2022/05/08 10:52
raimon49
＞すべてのシステムにおいて共通して「論理削除」を確立します。 / さらっとすごい目標を掲げてる。
2022/05/08 11:07
asuka0801
これ仮にAPI分かれていたとしても同じような事故は起きるだろうし、「間違えた時に戻せる」設計にするべきなんだろうなぁ。
2022/05/08 11:37
IGA-OS
障害対応の事例
2022/05/08 11:38
toaruR
Sourcetreeが微妙なので近づかないようにしている
2022/05/08 13:35
m_h
めも
2022/05/08 13:57
ya--mada
やるね、<q>しかし、一部のお客様の連絡先情報が削除されてしまったため、<略/> 当社はお客様の主要連絡先情報にすぐにアクセスすることができませんでした。</q>
2022/05/08 14:37
nabinno
身が引き締まる。
2022/05/08 15:33
anoncom
障害について、事象報告のみのアナウンスだけではなく、調査結果、対応についてすべて公開してるので事例としてタメになるしありがたい。
2022/05/08 15:36
degucho
コミュニケーションギャップこわい
2022/05/08 16:24
yarumato
“同様の事態を回避するための取り組み：すべてのシステムにおいて「論理削除」を確立し、論理削除のプロセスを経ていないデータ削除を防止します。削除イベントの復元を自動化します。”
2022/05/08 17:46
iekusup
ほー。
2022/05/08 19:38
heavenward
ちゃんと経緯報告あるの良い
2022/05/08 19:48
l83DK
ザ・ポストモーテム
2022/05/08 23:42
hdkINO33
“その結果、2022 年 4 月 5 日(火) 7:38 UTC から 8:01 UTC の間に 883 件のサイト (775 社のお客様に相当) が即座に削除されました。” こ、こわい……
2022/05/09 05:24
forest1040
障害報告
2022/05/10 01:35
takc923
全部論理削除にするの大変すぎるな。