ピンチの時ほど、大物っぽい行動をしないと・・。
その大物が、「悪者の大物」であっても良いんだけど、多くエンジニアは「善人」にできてるので真似できる人は少ないと思う。コソコソ隠してなかったことにしようという発想でも、「悪者の大物」のメンタリティがあればよいのだけど、でも、動揺してる時点で「悪者の大物」じゃないってこと・・。
> もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう
ここは笑ったけど、自分から言いだすのは確かに文化の違いかなぁ
他人に言ってあげたことはあるけど・・トラブって正常な判断が出来なくなってる人に対応させても良いことないからね。
でも日本の組織だと、凹んだやつを見つけるとここぞとばかりに叩く上司が多いんだよな
技術力がない人が上司になって、すべての責任を部下にって、よく見かけたなぁwww
Re:これが文化の違いか (#3154890) | GitLab.comが誤って本番DBを削除、バックアップも取れていなくて大騒ぎに | スラド
このあたりは参考にしたほうが個人的には良いと思う。
・こういうことをさらりといえるメンタルの強さ？と周りの理解？
・何かを起こした当事者には任せることを避けたほうが良い
YP氏は、おそらくpg_basebackupに空のデータディレクトリが存在することによって動作がおかしくなっているのだろうと考え、このディレクトリを削除することにした。しかしその1～2秒後、彼はその操作が（セカンダリの）db2.cluster.gitlbab.comにではなく、（プライマリの）db1.cluster.gitlab.comに対して実行したことに気がつく。
バックアップ手段のうち5つが機能していなかった
GitLab.comはデータのバックアップ手段をふだんから複数用意していたはずでしたが、実際にバックアップデータを確認したところ、そのほとんどが機能していなかったという悲惨な現実に向き合うことになりました。
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
はてなブックマーク - GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
まあ・・・
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickeyエンジニアレベルは高いかもしれないけど、運用レベルは相当低いよね。バックアップが有効でなかったって、有効でないことを検知する仕組みもなかったってことでしょ。
2017/02/02 13:38
これはあると思う。
ただし、必要な時に、バックアップがいろんな理由があって役に立たないというこは、感覚的には結構あり得ると思う。
必要でないときは、ちゃんと取れてるんだけどみたいな。
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey取ってるはずのバックアップが取れてない、バックアップがあっても書き戻せない、保管していたテープがエラーで読めない、等の事態はままあるので注意
2017/02/02 10:45
こういうのは大きな声ではいえないけど・・。
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey予防策なんて机上の空論。結局顔面蒼白で対応するしかない。
2017/02/02 08:48
そういう一面もある。運用系はちょっといやだなと思う。
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey他人に復旧をまかせた点は偉い。やらかした人が対応しないほうが良い。精神的にダメージがある中で、復旧作業にあたれば、余計ひどいことになる。冷静な別の人が復旧作業にあたるべき。
2017/02/02 12:00
結局、ゲーム感覚・遊び感覚でやれる人のほうが、成功確率高い気が・・・。
マニュアルどおりやる、基本を守る、組織のルールを守る
面倒でも、そういうのは守ったほうが良い。GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
- [gitlab]
- [仕事]
日本だと原因究明とか対策とかでいろいろ遅々として本作業に入れないような事案に対してのスピード感はいいね。だからといってこういう手法がいいかって問われると、どうなんだって思うけど。
2017/02/02 09:28
大規模なシステムほど、なんか無駄な作業が多いように感じるけど・・・。
本当に無駄な作業も混ざってるのは事実だけ、そういうノリで省略しだすと、泥沼にはまりかねないので・・・。
ファーストサーバ
開発担当藤原：OSからの削除コマンドが走ってはいたものの、HDDの物理プラッターにはデータが残っているだろうという推測のもと、バックアップ用のディスクを保全することにしました。そこで、データセンターにおいて、リードオンリーでHDDをマウントし直した後、都合700～800本のHDDを物理的に保全する作業を進め、サルベージ業者に復旧可能かを調べてもらうと共に、自身でもディスクの中のメタデータの復元や、カービングなどの処理は試してみました。
しかし、データ復旧の検証を進めていた開発・運用担当部門では、残念な「第2事故」を引き起こすことになる。
開発担当藤原：ある復旧ツールを動かしたところ、見た目上はファイルがまとめて復元されました。そこで、勇み足になって、いくつかのお客様のデータをリカバードファイルとして戻したのですが、実際はファイルシステムに一部不整合が出てしまい、本来アクセス権のない人が情報を参照できるようになってしまいました。
この結果、復旧したデータをすぐに取り下げ、ユーザーにはデータの破棄を依頼。さらに公開していた際にアクセスしたログを洗い出す必要が出てしまったという。
ASCII.jp：データ消失！あのとき、ファーストサーバになにが起こったか？ (1/2)｜データ消失事故から2年！ファーストサーバ、再生への第一歩
ファーストサーバ障害、深刻化する大規模「データ消失」 ：日本経済新聞
一方、今回のデータ消失事故の原因となった担当者は、配布システムが導入される以前から、自ら作成した更新プログラムを利用するなど独自の方法でシステム変更を行なっており、6月20日のメンテナンス時にも過去の更新プログラムを改変して利用したが、過去に記述していた「対象外サーバー群についてファイルの削除を行う」旨のコマンドを消し忘れていたという。
この担当者は更新プログラムを作成後、検証環境下で対象サーバー群に対して更新プログラムを実行したが、更新プログラムの不具合は「対象外サーバー群についてファイルを削除する」という内容であったため、不具合を確認できなかった。さらに、上長に許可を得ようとしたが上長は会議中で、前日に上長に対してメンテナンスを行う予定であることを報告していたことや、メンテナンスの内容自体はリスクの低い作業であったことなどから、先行ユーザーへの適用というプロセスも省いて、いきなり本番のシステム更新を実施。その結果、メンテナンス対象外だったサーバー群のデータがほとんど消失した。
調査委員会では、今回の担当者がマニュアルに従わない方式でメンテナンスを行なっていたことや、それを上長が認識していながら容認していたことなどはファーストサーバの過失にあたり、故意と同視できるほどの悪質な過失（重過失）には該当しないが、比較的重度の過失であったと解されるとしている。
ファーストサーバ、データ消失事故について第三者委員会の調査報告書を公表 -INTERNET Watch Watch
スポンサーリンク
コメントを残す