僕が障害復旧対応時に考えていることを言語化してみる - Qiita
これまで数多くのシステム障害を復旧してきました。 障害は無いに越したことは無いですし、起こらないように最善を尽くすのが我々エンジニアの使命です。 しかし、どれだけ最善を尽くしても起こる時には起こります。 今回は、これまで数多くの障害を復旧させてきたエンジニアが、復旧作業時に何を考えているのかを改めて言語化してみたいと思います。 こういう情報ってそれぞれのエンジニアの頭の中にあってあまり共有されないので、意外に参考になるかなと思います。 障害復旧対応の醍醐味 表現が適切かは分かりませんが、僕はシステム障害を復旧させるのが大好きです。目の前に起こっている事象からヒントを集め、地道に原因を切り分けてクリティカルヒットを見つけたときは名探偵になった爽快感があります。 加えて、動いているものを常に動かし続ける日頃の保守運用とは異なり、動いてないマイナスの状況を0まで戻すということで、復旧成功した際に
すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp
すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 全国銀行資金決済ネットワーク（以下、全銀ネット）とNTTデータは12月1日、2023年10月10日～11日にかけて全国銀行データ通信システム（以下、全銀システム）で発生した通信障害に関する報道関係者向けの説明会を開催しました。本件についてはNTTデータが11月6日に行った途中経過報告の内容をもとにレポートしましたが、今回、全銀ネットとNTTデータが揃って会見を行ったことで、より詳細な障害の原因が判明したので、あらためてその内容を検証してみたいと思います。 説明会の登壇者。左から、全銀ネット 企画部長 千葉雄一氏、事務局長兼業務部長 小林健一氏、理事長 辻松雄氏、NTTデータ 代表取締役社長佐々木 裕氏、取締役副社長執行役員 鈴木正範氏 なお、全銀ネットとNTTデータは、今回の障害に関して金融
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
書評「入門 監視」雰囲気で監視をやっているすべての人にオススメ | DevelopersIO
監視という一種マニアックな領域を真正面から解説した貴重な本です。監視で悩む人のみならずシステム開発に携わるすべての人にオススメ。 「全然わからない。俺たちは雰囲気で監視をやっている」 自分はAWS事業本部コンサルティング部所属ということもあって、いろんなお客様にAWSインフラのコンサルティングしてます。最初のインフラ構成設計時に監視の話をすることも非常に多いんですが、 「どうしましょう。CloudWatchでいけますかね？」 「MackerelとかDatadogとかもありますが、どうしましょ。マネージドとの違いは〜」 「とりあえず、ディスク使用率80%でしきい値設定しておきましょうか。みんなそうしてますよ」 とか言っていた昔の自分に見せつけたい本、それが今回紹介する「入門 監視」。 監視設計の原則がよくわかんない メトリクスのしきい値決めるところから監視を考えてしまいがち よく考えずに、い
インフラエンジニアの独り言、ストレージは盲点になりがち - orangeitems’s diary
インフラエンジニアの世界 IT技術者というと世間から見たら、要件定義やシステム設計をおこなうシステムエンジニアと、それを実装するプログラマーしか見えてないと思うんですよね。でもその基盤を動かすインフラエンジニアという人たちが全体の10パーセント弱（肌感）存在しています。 インフラエンジニアと言ってもまたそこから役割分担があって、物理サーバーやOSに強いサーバーエンジニアと、ネットワークに強いネットワークエンジニアがいます。大昔は物理サーバーとネットワークしかインフラに無かったので、大体はこの二極化でした。ネットワークエンジニアはスイッチやファイアウォール、ロードバランサーくらいまでは自分の領域としてくれていますが、OSやミドルウェアのことになると、それは私の領域ではない発言が出てサーバーエンジニアをブチ切れさせること請け合い。逆にネットワークエンジニアはサーバーエンジニアがなんでもネットワ
DBが真っ白になっても55分で完全復旧ができるまでの道 | CyberAgent Developers Blog
初めまして。サイバーエージェント技術本部インフラエンジニアの@prog893です。今回は「AWA」という音楽ストリーミングサービスのMongoDBクラスタの復旧時間を短縮するために行ったインフラの改善について紹介したいと思います。復旧時間が12時間から55分まで短縮できたのですが、皆さんの参考になれば幸いです。（※注意：今回紹介する施策はAWAのインフラ構成や設定のものであり、他の環境で同じような効果が得られるとは限りません） AWAのデータストア構成 まず、現在のデータストア構成について軽く説明します。こちらの図でAPIサーバ，MongoDBに関連する構成の概要を示します： AWAのデータストア構成概要 メインのデータストアとしてはMongoDBを使っており、MongoDBのインスタンスはAWSで管理しています。APIサーバ、MongoDBのインスタンスがそれぞれのプライベートサブネット
2017年8月25日の大規模インターネット障害:Geekなぺーじ
先週の金曜日、Googleが誤った経路をインターネットに流したことによって、大規模な通信障害が発生しました。 大きな影響を受けたのが日本のOCNとKDDIだったとされていますが、様々な事業者が影響を受けたようです。 ネットワーク障害 グーグルが設定誤りで謝罪 グーグルが謝罪 大規模ネット障害、装置の誤操作が原因 ニュース解説 - 米グーグルの設定ミス、なぜ日本の大規模ネット障害を引き起こしたのか？：ITpro BGP leak causing Internet outages in Japan and beyond 8月25日に発生した大規模通信障害をまとめてみた 今回の障害は、世界中の組織とBGP(Border Gateway Protocol)で繋がっている巨大なネットワークを持つ「Googleだからこそ」の事例と言えそうです。 ここでは、その理由を紹介します。 ネットワークのネットワ
[PDF] 08/25の通信障害概説
08/25の通信障害概説 Matsuzaki ‘maz’ Yoshinobu <maz@iij.ad.jp> maz@iij.ad.jp 1 観測されている概要 • 2017/08/25 12:22JST頃 • AS15169が他ASのIPv4経路をトランジット開始 • ⽇頃流通しない細かい経路が⼤量に広報 • これによりトラヒックの吸い込みが発⽣ • 国内の各ASで通信障害を検知 • 2017/08/25 12:33JST頃 • AS15169がトランジットしていた経路を削除 maz@iij.ad.jp 2 観測された問題のBGP経路概要 • 経路数 • 全体で約11万経路 (⽇本分が約25000経路) • /10から/24まで幅広い経路(半数程度が/24) • 通常流れていない細かい経路が多かった • AS PATHは概ね “701 15169 <本来のAS PATH>” • 広報元A
冗長化の難しさとNetflixの答え｜こんぴゅ
この世には、ダウンすることが許されないシステムが存在する。金融機関の基幹系、原子力発電所や鉄道の制御システム、流通業の物流管理システムなどはもちろんであるが、最近ではtoCのサービスでもダウンタイムが長くなると大事件として騒がれ、ヤフトピに載ってしまったりする。 ではダウンへの対策はどうするかというと、いくつか手法はあるのだけど代表的なのは「冗長化」である。簡単に言うと、全く同じシステムを裏側に待機系として用意して、有事の際は自動的に切り替わるようにしておくのである。素朴だが、殆どのシステムではこの種の仕組みを用意している。 それでうまくいけばいいのだけどじつは、この待機系への切り替えというのは鬼門であり、高確率で失敗する事になる。 ［続報］東証のシステム障害、原因はハードウエア故障後の切り替えミス http://itpro.nikkeibp.co.jp/article/NEWS/2012
猿が暴れてクラウドの障害に強くなるNetflixのシステム - ワザノバ | wazanova.jp
http://techblog.netflix.com/2013/10/introducing-chaos-to-c.html 「歴史上の有名な開発プロジェクトからまなぶべきこと」をまとめていたときに、Videoの中で、ある大型ロケットエンジンの開発において、信頼性テストのために小型爆弾をエンジンの噴射口辺りで爆発させて耐性を調べた云々のエピソードが紹介されていて、更に続いて「ネット業界で同じようなことをやってるのはNetflixぐらいだ。」という説明がありました。その時は何のことだかよくわからなかったのでブログでは取り上げなかったのですが、今回見つけました。 以前紹介したように、北米のインターネットトラフィックの30%以上を占めるNeflixはインフラをAmazonに全面的に移行しています。クラウドに移行した後の学びとして、 自社データセンターの時は、個別のハードウェアインスタンスが障害
AWS大規模障害を乗り越えたNetflixが語る「障害発生ツールは変化に対応できる勇気を与えてくれる」 | さくらのナレッジ
このコラムのNetflixの「FIT（障害注入テスト）」について書いた記事を執筆した直後のことですが、Netflixのサービスをある災害が襲いました。AWS（Amazon Web Services）のus-east-1リージョン全体で大規模障害が発生したのです。 この大規模障害を同社がどのように乗り切ったか。その一部が以下のBlog記事で明かされています。 Chaos Engineering Upgraded 「AWSリージョンが落ちることはめったにない。だが、それは実際に起こった」と記事では語っています。2015年9月20日、US-EAST-1リージョンのAmazonのDynamoDBサービスが、問題が発生して停止します。これは20以上のAWSサービスに影響を及ぼしました。その影響により、AWSをインフラとする複数のインターネットサービスが6〜8時間にわたってダウンしてしまったのです。
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 米国でビデオオンデマンドサービスを提供しているNetflixは、Amazonクラウド上でわざとシステム障害を起こすためのツール、Chaos Monkeyをオープンソースで公開しました。 Chaos MonkeyはAmazonクラウド上で使うツール。Amazonクラウド上のインスタンスをランダムに落としまくることで、サービスに対して仮想的な障害を引き起こしてくれます。 NetflixはこのChaos Monkeyを実環境で使うことで、本物の障害が起きたとしてもサービスが継続できることをテストし続けてきました。Netflixのブログ「Chaos Monkey released into the wild」から引用します。 There are many fail
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「サル軍団」にシステム障害を起こさせる、Netflixの驚異的なトラブル撲滅法
TechCrunch
人間は誰でもミスをする、システムは必ず障害を起こす──トラブルを減らす“6つの知恵”