タグ

障害に関するymm1xのブックマーク (56)

  • 障害対応で一番最初にやるべきことは全体への周知じゃね? - Qiita

    結構「障害対応ハウツー」みたいなのはググればいくらでも記事が出てくるけどここに言及してる記事が案外少ないなあと思ってどうしても書きたくなりました. 新人でもすぐできるからぜひ覚えてもらいたくて「新人プログラマ応援」のタグも付けました. 監視ツールの通知によってとか, 誰かに「このページ見れなくなってるよ」って教えてもらうとか, 何らかの手段によってエンジニアが障害の発生に気づいたとき, 一番始めにやることは全体への周知だと思っています. 「一番始めに」 一番始めにというのは, まさに何を差し置いても一番始めにということです. 障害に気づいたエンジニアはつい 「どこのページだ」 「レスポンスタイム10秒って出てるけどホントかよ試しに俺もアクセスしてみよう」 「さっきのデプロイが原因じゃねえか?」 などと口走りがちですが, これらの気持ちをグッと堪えてまずは周知に意識を向けるべきです. 「全体

    障害対応で一番最初にやるべきことは全体への周知じゃね? - Qiita
    ymm1x
    ymm1x 2018/06/29
  • メルカリの3つのValueで取り組むインシデント対応 | メルカリエンジニアリング

    TL;DR こんにちは、SRE の @masartzです。 メルカリには Go Bold、 Be Professional、All for One という3つの行動指針(Value)があります。今回はこれらのValueを元にメルカリでインシデント対応をどのように行っているかを紹介します。 インシデント対応とは エントリでは、いわゆるハードウェアやネットワークなどのインフラにおける不具合や故障だけでなく、プロダクトひいては会社活動全般における非日常的な状況に対する対応をインシデントと定義して進めます。 何をやっているか インシデント対応は、障害の発生から根解決までの過程で大きく2つの段階に分けられます。 障害発生から一旦の収束まで 発生した障害を監視システムなどで検知します あらかじめ用意された専用のSlackチャンネルに共有し、対応を開始します 状況の把握と早期の復旧に務めます 機能の

    メルカリの3つのValueで取り組むインシデント対応 | メルカリエンジニアリング
  • Downdetector

    © 2012-2024 Ookla, LLC., a Ziff Davis company. All Rights Reserved. Downdetector® is among the federally registered trademarks of Ookla® and may not be used by third parties without express written permission.

    Downdetector
    ymm1x
    ymm1x 2018/04/06
  • エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

    システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた!ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生

    エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
    ymm1x
    ymm1x 2018/01/28
  • mixi大規模障害について 解明編 - mixi engineer blog

    こんにちは、システム技術部たんぽぽGの森です。 先日のmixi大規模障害の原因となったmemcachedの不具合の詳細な解明ができました。 再来週まで発表を見合わせようと思ったのですが、早くお伝えしたほうがいいと思いましたので公開発表致します。 memcachedとlibevent memcachedはlibeventというライブラリを使用してクライアントからの要求(接続、コマンド送信)を処理しています。 libeventを使用するにはevent_baseという構造体を用います。 main threadはmain_baseを使用します。 static struct event_base *main_base; ... int main (int argc, char **argv) { ... main_base = event_init(); ... /* enter the ev

    mixi大規模障害について 解明編 - mixi engineer blog
  • CARAVAN STORIES

    ファンタジーRPG『CARAVAN STORIES』新コンテンツや新キャラクターが続々登場!PC版はiOS版/Android版とのクロスプラットフォーム対応で同じデータをシチュエーションに応じてプレイ可能!

  • ヘルプ | Chatwork

    検索したい言葉を入力後、ENTERボタンを押してください。 (例:パスワード 変更) よくある質問 トップ記事1〜5 管理者が組織契約のユーザーを削除した場合 ログインメールアドレス・名前を変更する ログインメールアドレスがわからない モバイルの機種変更や紛失に備えて必ずしておくこと 新規登録のアカウント登録メールが届かない トップ記事6〜10 ビジネスプラン・エンタープライズプランの利用料金 プラン変更時にデータは引き継がれますか? ダウングレード、プラン変更できますか? タスク管理機能について グループチャットについて サービス ビジネスプラン/エンタープライズプランへのアップグレード フリープランと有料プラン(ビジネスプラン、エンタープライズプラン)の違いは? 他のコミュニケーションツールとは何が違いますか? どのような企業が利用していますか? 導入事例を教えてください。 モバイル端

    ymm1x
    ymm1x 2017/11/17
  • [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

  • AWS でいままで起きた大規模障害を振り返る - Qiita

    目的 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ使っているリージョンで同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。 所感 毎年どこかのリージョンで大規模な障害が起きている ap-northeast-1 で起きていないのはたまたま、運がいいだけ AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの ステータスダッシュボードは時に嘘をつく クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある Chaos Monkey の思想は必須 報告書読むの面白い AWS の中身がすこし透けて見えてきます 前回データセンターについて調べたことが役に立った AWS のデータセンターに侵入する(妄想で) - Q

    AWS でいままで起きた大規模障害を振り返る - Qiita
  • https://jp.techcrunch.com/2017/03/03/20170302aws-cloudsplains-what-happend-to-s3-storage-on-monday/

    https://jp.techcrunch.com/2017/03/03/20170302aws-cloudsplains-what-happend-to-s3-storage-on-monday/
  • https://jp.techcrunch.com/2017/03/01/20170228amazon-aws-s3-outage-is-breaking-things-for-a-lot-of-websites-and-apps/

    https://jp.techcrunch.com/2017/03/01/20170228amazon-aws-s3-outage-is-breaking-things-for-a-lot-of-websites-and-apps/
    ymm1x
    ymm1x 2017/03/01
  • マイニンテンドーストアのアクセス障害に関するお詫びと『ファイアーエムブレム Echoes もうひとりの英雄王 VALENTIA COMPLETE』の販売方法変更および予約開始日延期のお知らせ|サポート情報|Nintendo

    マイニンテンドーストアのアクセス障害に関するお詫びと 『ファイアーエムブレム Echoes もうひとりの英雄王 VALENTIA COMPLETE』の 販売方法変更および予約開始日延期のお知らせ 2017年1月23日(月)にオープンしましたマイニンテンドーストアにおきまして、想定をはるかに上回るアクセスにより、多くの方に長時間ご利用いただけない状態となり、Nintendo Switchなどの商品をお買い求めのお客様に大変ご迷惑をおかけしましたことを深くお詫び申し上げます。 この事態を受けまして、数量限定商品としてご案内しておりました『ファイアーエムブレム Echoes もうひとりの英雄王 VALENTIA COMPLETE』は、受付期間中にご予約をいただいたすべてのお客様に販売することといたします。 なお、この準備のため、1月27日(金)に予定しておりました予約受付開始は、一旦延期とさせて

  • 2016年8月末より発生している国内サイト・サービスの接続障害についてまとめてみた - piyolog

    2016年8月22日頃から、日の複数サイトで接続し難い、あるいは出来ないといった事象が確認されています。ここでは関連情報をまとめます。 サーバー(Webサイト)への接続等で障害発生しているサービス、サイト 各サイトのTwitter等での発表をまとめると次の通り。 障害発生元 発生原因(運営元発表抜粋) さくらインターネット DoS攻撃、あるいは攻撃と思われる 技術評論社 サーバへのDoS攻撃が検知されたことを受け,サービスが提供できない状態 スラド DDoS攻撃の影響 はてな さくらインターネットDNSサーバー障害に起因 したらば掲示板 ネットワーク障害 ふたば★ちゃんねる サーバ会社よりDoS攻撃との報告 小説家になろう 上位回線の管理会社よりDos攻撃を受けているとの連絡 OSDN DDoS 攻撃の影響 Feeder 全サーバがDDoS攻撃を受けており、サービスをご提供できない状態

    2016年8月末より発生している国内サイト・サービスの接続障害についてまとめてみた - piyolog
  • ウィルス感染でWebサービスが20日間ダウン。本当にごめんなさい - Qiita

    障害が起きたWebサービスは個人で運営しているサービスです。 2016年2月、障害から20日後にサービス再開しましたがアクティブユーザは以前の18%です。未だ回復の目処は立っていません。冗長化していないサーバがウイルス感染し、その後の対応も後手後手に回ってしまいました。 2016年1月末に起こるべくして起こった障害について記事にしてみました。ご迷惑をお掛けしてしまい当に申し訳ありません。 ■ ユーザは、もう戻ってこない どんなウイルスに感染したのか SYNフラッド攻撃(SYN Flood Attack)を他のWebサイトに行うウイルスに感染して、確認していませんが他のサービスをSYNフラッド攻撃していたと思います。またウイルス感染時にサーバのsshdを書き換えられsshで接続できなくなりました。感染後にコンソールログインして書き換えられた醜い authorized_keys を見た時ゾッ

    ウィルス感染でWebサービスが20日間ダウン。本当にごめんなさい - Qiita
  • GitHub、1月末のダウンの原因はデータセンターでの停電と説明

    ソースコード共有ツールを運営する米GitHubは1月29日(現地時間)、日時間の28日(木曜日)の午前9時ごろから約2時間にわたってサービスがダウンしたことについて謝罪し、原因は自社データセンターでの停電だったと説明した。 GitHubの障害は世界規模のものだった。同サービスの利用者は現在、世界で970万人以上。政府機関や大手企業も利用しており、日でも日立システムズ、ヤフー、サイバーエージェント、グリーなどが導入している。 GitHubは、同社の一次データセンターでの短い停電が連鎖的障害を引き起こし、GitHub.comの運用にとって重要な多くのサービスに影響を与えてしまったと説明する。障害の発生は世界協定時(UTC)の28日午前0時23分で、同日午前2時32分(日時間の28日午前11時32分)には復旧したとしている。 同社は「われわれのサービスのいかなる障害でも皆様の仕事に影響を与

    GitHub、1月末のダウンの原因はデータセンターでの停電と説明
  • DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3

    はじめに データセンタ障害の話題がちらほら流れておりますが、その中で見かけた「データセンタでそんな障害あったら意味ねえじゃん」みたいなコメントにちょっと引っかかるところがありまして。まあ確かに電源の二重化云々とかいろいろ災害やトラブルに対する対策はしてますよ。してますけど、でもデータセンタ・オーダーの障害とかも実際あるんですよね。落ちるときは落ちるんですよデータセンタだろうと。信頼性は高いけど100%じゃない。 ということで、じゃあ過去どんな事例があったのか、ざっと事例を挙げてみようと思いました。基的には過去の私のツイートとかはてブとかネットをざーっと検索して出てくるものを取り上げています。「データセンタ使ってるからオールオッケー」みたいな話ではなくて、その上で・さらにこういうこともあるんだ、という話を見るのに参考にしてもらえれば良いかと思います。 なお、ここで取り上げている事例は、特定

    DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3