タグ

関連タグで絞り込む (156)

タグの絞り込みを解除

障害に関するlocke-009のブックマーク (157)

  • SRE導入: システムを安定させる4000万円の魔法の壺 - MonotaRO Tech Blog

    こんにちは。鈴木です。 ここにシステムを安定させる4000万円の魔法の壺があるとします。 あなたなら買いますか。 はじめに SREやればいいのに 4000万円の魔法の壺 なぜモノタロウはSREに取り組むのか 10分落ちると数百万円、数千万円の影響が出る 不安定なシステムを札束でしばいたことがある 大規模化・複雑化が旧来の運用方法を無効化する SREの導入による効果 会話の中に「SLO」が登場するようになった システムの状態を深く理解できるようになった オンコールの初動対応が早く精緻になった SREの難しさ 組織横断的な活動の難しさ 安定的に時間を使うことの難しさ 利用するツールやサービスの難しさ どのようにSREを導入したのか Googleの最新SREを学んだ CUJを定義した SLIとSLOを定義した Cloud Monitoringでダッシュボードを作成した 役に立つかもしれない話 可

    SRE導入: システムを安定させる4000万円の魔法の壺 - MonotaRO Tech Blog
  • ITインフラの障害時、「今どうなってるんだおじさん」にならないために 必要な心構えを考える

    先日、KDDIが大規模な通信障害を起こした。社会インフラである携帯電話に関する障害ということもあって影響は大きく、SNSでもさまざまな話題のタネになった。障害対応をしている真っ最中の現場など、関係各所に「今どうなってるんだ」と怒鳴り込み、解決を遅らせる「今どうなってるんだおじさん」もその一つだ。 例えばauの障害時は、auショップに怒鳴り込む人が相次いだという。総務省がKDDIに幹部を直接送り込んだ報道に対しても「『今どうなってるんだおじさん』ではないのか」と疑問視する声が見られ、後に総務省が「足を引っ張ったわけではない」と詳細を説明していた。 実はこの問題、携帯回線だけでなく、クラウドなど、他のITインフラの障害時にも起こり得る。もし周りでITインフラが障害を起こしたとき、今どうなってるんだおじさんにならないためにどんな考え方をすればいいのか。auの一件や、エンジニアコンサルタントとし

    ITインフラの障害時、「今どうなってるんだおじさん」にならないために 必要な心構えを考える
  • Googleでもやっている障害対応訓練の「Wheel of Misfortune」をやってみた。 - MonotaRO Tech Blog

    序文 こんにちは。MonotaROの伊藤です。 弊社では障害対応訓練の実施手法の一つであるWheel of Misfortune(略称:WoM)を実践しています。WoMの導入で、障害対応体制の強化を行うことができましたので、実施までの経緯や得られた学びなどを中心に紹介したいと思います 序文 運用担当者の負荷が高まり続ける問題 運用担当者=社歴が長いベテランエンジニア 運用のスケールアウト 障害対応訓練をやってみよう 訓練環境の準備の問題 訓練シナリオの問題 外部からの助け Wheel of Misfortuneとは 実施時の様子 シナリオ開始時の様子 モニタリング画面の表示 WoMとDiRT(Disaster in Recovery Training) 障害対応訓練をやってみた結果 準備時点で感じたメリット 手順書の不備を発見できたこと 障害が起こりかねない場所を考えるきっかけになったこと

    Googleでもやっている障害対応訓練の「Wheel of Misfortune」をやってみた。 - MonotaRO Tech Blog
  • 運用者がいかに早くシステムの異常を発見できるか、ITレジリエンスを高める検知策のルールを解説

    システム開発において使われるようになってきたレジリエンスという言葉。「回復力」「弾力性」を意味し、ITサービスがシステム障害、災害、サイバー攻撃などにより誤作動や停止に至った際に、迅速な回復を図り、サービスを正常な状態に復旧する能力を指します。今回はレジリエンスのうち、異常や問題を発見するための検知策のルールを書籍『ITレジリエンスの教科書』(翔泳社)から紹介します。 記事は『ITレジリエンスの教科書 止まらないシステムから止まっても素早く復旧するシステムへ』(大和総研 )の「2-4 検知策に関するルール」から一部を抜粋したものです。掲載に際して編集しています。 検知策に関するルール 検知策は、「監視などでイレギュラーな事象を早期に見つける対策」であり、予防策でリスクをカバーしきれずに残念ながらシステム障害として顕在化してしまった場合、あるいはその予兆がある場合にいち早く発見する策です。

    運用者がいかに早くシステムの異常を発見できるか、ITレジリエンスを高める検知策のルールを解説
  • KDDIを襲った多重のワナ 通信障害では結局、何が起きていたのか

    KDDIを襲った多重のワナ 通信障害では結局、何が起きていたのか:田雅一の時事想々(1/5 ページ) 7月2日、午前1時25分から始まったau回線の通信障害では、結局何が起きていたのか。 KDDIの高橋誠社長は29日、決算発表に先立って、謝罪の言葉と障害の概要、最初防止対策などについて報告をした。より技術的で詳細な背景については、別途、総務省への報告が行われるだろう。 高橋社長によると発生期間は61時間25分におよび、音声通話障害の影響を受けた加入者は約2278万人、データ障害に関しても765万人以上と、まさに過去最大の障害だった。 障害発生のおおまかな経緯は、障害発生中に行われた3日の記者説明会でも説明があった。ただ、不可解だったのはその後の完全復旧が予想以上に遅く、発話できない状態が続いたことだ。今回の説明会では、復旧作業中の時点では判明していなかった3つ目の障害が発生していたことが

    KDDIを襲った多重のワナ 通信障害では結局、何が起きていたのか
  • KDDI通信障害、「約款返金271万人」と「おわび返金200円」の根拠は?

    KDDIが、7月2日から4日にかけて発生した通信障害に関するユーザーへの返金を発表した。 返金の内容は2通りある。まず、契約約款に基づく「約款返金」として、障害が発生した期間中、24時間連続して通信サービスを利用できなかったユーザー271万人に対し、契約している料金プランの基使用料から2日分相当額を減算する。2日分としたのは、通信障害が発生した期間が7月2日1時35分から4日15時までの合計61時間5分で、丸24時間使えない期間が2日間だったため。

    KDDI通信障害、「約款返金271万人」と「おわび返金200円」の根拠は?
  • 障害対策のサブ回線に必要 eSIMが使えるサービスの手数料や手続対応を比べた (1/2)

    au(KDDI)の長時間にわたる通信障害もあり、回線トラブル時の対策を考えようと思った人も多いはず。まず、思いつくのはデュアルSIM機を使うことだが、iPhoneをはじめ、最近では2枚目のSIMにeSIMを用いるスマートフォンが増えている。そこで、eSIMに対応した主な通信サービスをピックアップした。 eSIMはデュアルSIMの利用に不可欠という時代に ケータイが使えないという大規模な通信障害は定期的に発生している。7月2日未明からのauの障害はほぼ復旧という段階まで2日以上かかり、完全復旧の宣言までは3日を要した。ここまで長い障害は経験がない。 今回はauネットワークの問題だが、他社も障害自体は過去に発生させており、auネットワーク以外を使っているからと安心できない。 そこで思いつくのが予備回線の確保。昔なら「もう1台ケータイ」だったが、今はデュアルSIM機が普及して、1台のスマートフォ

    障害対策のサブ回線に必要 eSIMが使えるサービスの手数料や手続対応を比べた (1/2)
  • 知って納得、ケータイ業界の"なぜ"(120) KDDIの大規模通信障害から考える、モバイル通信の重要性が高まる時代の“備え”

    2022年7月2日深夜に発生したKDDIの通信障害は、完全復旧まで86時間にも及び、コミュニケーションだけでなく社会活動にまで大きな影響を与える非常に規模の大きなものとなった。だがその通信障害の内容からは、KDDIだけでなく携帯電話会社全体で、同様の規模の障害が今後も発生する可能性が十分あり得るようにも感じる。我々はどのような対処をすべきなのだろうか。 KDDIは当にNTTドコモの教訓を生かせなかったのか? 先の週末に連日報道がなされ、大きな注目を浴びたKDDIの通信障害。2022年7月2日の深夜に発生し、2022年7月5日の15時に完全な回復が確認され、復旧宣言がなされるまで86時間、3日以上にわたってKDDIの通信サービスを利用している人が通話や通信がしづらい状況が続いたというのは、既に多くの人がご存知の通りだ。 KDDIは86時間にわたる大規模通信障害を発生させ、社会的にも大きな影

    知って納得、ケータイ業界の"なぜ"(120) KDDIの大規模通信障害から考える、モバイル通信の重要性が高まる時代の“備え”
  • KDDI完全復旧でも「端末によって不具合が残る」 吉村専務「電源のオン/オフを」

    KDDIは7月5日、全国で発生したauなどの通信障害について記者会見を開いた。2日午前1時35分から発生した障害は、5日午後3時36分に復旧した。 具体的には、音声通話のトラフィック・発着信の成功率が前週比の同等まで回復していることを4日午後3時から約24時間確認したため、全国的に復旧したと判断した。 端末によってはいまだに不具合 「電源のオン/オフを」 しかし、端末によってはいまだに不具合が起こる場合がある。その場合について、電源を一度切り、再起動させることで解消されるという。 技術統括部長の吉村和幸専務は「現在、ネットワークとしては回復しておりますが、端末によってセッションが残ってしまう場合があります。その場合は、電話機の電源オン/オフの操作をお試しいただいております。現在の(不具合が起きている端末の)数について、ゼロにはなっていないと思います」と説明した。 総務大臣の指摘 「報告の

    KDDI完全復旧でも「端末によって不具合が残る」 吉村専務「電源のオン/オフを」
  • 「au通信障害」完全復旧のKDDI会見質疑詳報、総務省幹部も入った復旧作業の舞台裏は

    「au通信障害」完全復旧のKDDI会見質疑詳報、総務省幹部も入った復旧作業の舞台裏は
  • 山田祥平のニュース羅針盤(339) 通信障害に備えてキャリアWi-Fiを確認しておこう

    なんだかとても後味の悪い記者会見だった。説明するための情報がまだ揃っていない段階での会見だったからだ。 7月3日の日曜日、手元のメールボックスに配信されたKDDIの広報部からの説明会開催の案内メールは7時35分に受信されていた。当日、11時から記者会見を実施するという(会見の内容はレポート記事「KDDI最大の通信障害、なぜ起きた? 緊急会見で分かったことを整理する」で紹介されている)。 KDDIが7月3日に開催した緊急記者会見。代表取締役社長の髙橋誠氏(右)と、執行役員専務 技術統括部長の吉村和幸氏が謝罪した 「復旧未定」KDDI始まって以来の大規模通信障害 7月2日(土)の深夜から発生したKDDIの通信障害は、同社始まって以来の規模だという。 24時間を超え、会見開始時刻の7月3日11時時点では、関西エリアで復旧作業は完了、50%の規制をしつつ徐々に平常のネットワークへの復帰が進行中、

    山田祥平のニュース羅針盤(339) 通信障害に備えてキャリアWi-Fiを確認しておこう
  • au通信障害、「デュアルSIM」を使えば大丈夫だった? スマホユーザーが考えたい有事への備え

    au通信障害、「デュアルSIM」を使えば大丈夫だった? スマホユーザーが考えたい有事への備え(1/2 ページ) 7月2日から4日にかけて起きたKDDIの大規模な通信障害。同社史上最大という今回の障害では、個人向け・法人向け問わず最大3915万回線が影響を受けたという。発生当初はTwitterなどでユーザーから困惑の声が続出。事態を回避しようと試行錯誤する人の声も相次いでいた。 中でも話題になったのは。SIM(加入者識別モジュール)カードを2枚使い、1台のスマートフォンで2つの回線を使えるようにする「デュアルSIM」だ。片方の回線が使えなくなっても、もう片方が使えればトラブルに備えられるので、ユーザーが取れる障害対策として注目を浴びた。 今回の障害は休日に起きたが、仮に平日だった場合、BYODのスマホが使えないといった問題につながり、仕事に支障が出る可能性もある。今後、KDDI以外の通信キャ

    au通信障害、「デュアルSIM」を使えば大丈夫だった? スマホユーザーが考えたい有事への備え
  • エンジニアとしてauの会見を見てみたら、幹部たちの聡明さに好感度があがった話「auを選んでよかった」「社長の技術力」

    Kobayashi Yasuhiro @ppyv 技術者の端くれとしてKDDIの会見を見ていたが、KDDIに対する好感度がかなり上がった。幹部があらゆる質問を打ち返せているし(なにより驚いたのは社長がiOSとAndroidの仕様差分に言及した点)、慌てふためいたり助けを求めたりするシーンがまるでない。 2022-07-03 12:05:13

    エンジニアとしてauの会見を見てみたら、幹部たちの聡明さに好感度があがった話「auを選んでよかった」「社長の技術力」
  • 障害報告書を書こう! - Qiita

    担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告(レポート)する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例: ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「当の原因は…」 できるだ

    障害報告書を書こう! - Qiita
  • au通信障害、復旧を遅らせた「輻輳」って何? 過去にはドコモも

    7月2日に発生し、現在も完全復旧には至っていないKDDIの大規模通信障害だが、多方面に影響を与えたことでも大きな注目を集めている。その原因は音声通話処理に関する部分で「輻輳」(ふくそう)が発生したためだというが、そもそも輻輳とはどのようなもので、なぜそれが通信障害を起こすほど甚大な影響を与えてしまうのだろうか。 甚大な影響を与えたKDDIの通信障害、その原因は 大規模通信障害は「au」「UQ mobile」「povo」など、KDDIが提供するモバイル通信の利用者のほぼ全てに影響しただけでなく、KDDIのモバイル回線を利用している楽天モバイルやMVNO、さらにはKDDI回線を利用する多くの企業のサービスにも影響を与えることとなった。 実際この通信障害により、KDDI回線を利用していた銀行の店舗外ATMが使えなくなったり、宅配便サービスの配送情報が更新されなくなったり、気象観測点の一部データが

    au通信障害、復旧を遅らせた「輻輳」って何? 過去にはドコモも
  • KDDI“過去最大”の通信障害、発生の経緯は? 緊急会見で判明したこと

    何が起きたのか 7月2日の午前1時35分頃から、全国の携帯電話ユーザーがau網での音声通話やSMS、モバイル通信サービスを利用しづらい状況が発生した。また、一部のIoT機器で通信しづらくなる状況となった。 通信状況はデータ通信を中心に復旧が進んでおり、ユーザーごとに徐々に利用できる状況に回復している。西日エリアでは富山県、長野県、静岡県以西の西日エリアでは、音声通話の復旧作業についても3日11時ごろに完了している。ただし、ネットワーク試験などを実施するため、発着信やデータ通信の総量を制御する“流量制御”を行っており、しばらく利用しづらい状況が続いている見通し。 東日エリアでは17時30分に復旧作業が終了した。 通信障害の影響は、端末やOS(プラットフォーム)によっても異なる。音声通話は利用できないか、利用しづらい状況が3日17時の時点でも続いている。スマートフォンなど音声回線を利用す

    KDDI“過去最大”の通信障害、発生の経緯は? 緊急会見で判明したこと
  • KDDIの通話・通信障害メモ - show log @yuyarin

    この記事は7/3午前中に記載したもので、まだKDDI社長の会見内容を反映していません。 今回のKDDIの障害が具体的にどういうサービスに影響が出るのものか、モバイルネットワーク初心者としてLTE/EPC/IMS周りの挙動の勉強のためにまとめてみた。 はじめにまとめ モバイルの通信には音声通話とデータ通信があり、今回主に長時間の障害を受けたのは音声通話(IMS)の方だった。 7/2(土)の日中帯はデータ通信はできるが音声通話やそれに付属するサービスが利用できない状態が継続していた。データ通信も不安定な状態になっていた。 端末の実装(主にAndroid端末)によっては音声通話ができないとデータ通信も止めてしまう挙動があった。これによりLTEを回線として使用しAndroidベースで構築された決済システムなどが利用不可能な状態が継続した。 音声通話(IMS)が利用できないと、通常の電話はもちろん、

    KDDIの通話・通信障害メモ - show log @yuyarin
  • auの障害、報告ページを見るだけで胃が痛い…一時間に一回、進展のない事を淡々と報告せざるを得ないリリース「ある意味これは誠意」

    たにぐち まこと/学ぶ。をちゃんと @seltzer 『よくわかるPHPの教科書』や『マンガでマスター プログラミング教室』の著者。 ともすたで、プログラミング教育やこども向けの講座などを Udemyや YouTubeで展開しています。チャンネル登録こちら ≫ 01w.me/tomo tomosta.jp たにぐち まこと/学ぶ。をちゃんと @seltzer auの障害、報告ページを見るだけで胃が痛い。1時間に1回、進展のないことを淡々と報告せざるをえないリリース。一見すると味気なく見えるが、これを毎時間エンジニアから「進展なし」と伝えられて、同じ文面をアップし続ける担当者さんもなかなかの試練。がんばれ。 pic.twitter.com/v3lLcLorNP 2022-07-02 21:44:05

    auの障害、報告ページを見るだけで胃が痛い…一時間に一回、進展のない事を淡々と報告せざるを得ないリリース「ある意味これは誠意」
  • KDDIの通信障害についてまとめてみた - piyolog

    2022年7月2日、設備障害によりKDDIの携帯電話サービスで障害が発生しました。ここでは通信障害に関連する情報をまとめます。 通信障害発生から復旧発表まで3日以上 au携帯電話サービスがご利用しづらい状況について 障害発生同日8時以降から1時間おきに障害報告が公表されていた。 障害発生・復旧の状況は以下の通り。 対象地域 障害発生日時 復旧作業終了時間 復旧完了日時 西日 2022年7月2日 1時35分頃 2022年7月3日 11時頃 2022年7月5日15時36分 東日 2022年7月2日 1時35分頃 2022年7月3日 17時30分頃 2022年7月5日15時36分 影響を受けたのは全国の個人・法人向けのau携帯電話、UQ mobile携帯電話、povo、au回線利用事業者の音声通信、ホームプラス電話、ホーム電話、auフェムトセル、SMS送受信。7月3日11時時点の概算では約3

    KDDIの通信障害についてまとめてみた - piyolog
  • 2022年6月21日に発生したCloudflareの大規模障害の原因 - Qiita

    概要 今回は、2022年6月21日に発生したCloudflareの大規模障害についての原因がまとめられた記事が公開されたため、その内容について翻訳およびサマライズしていきます。 何が起こったのか 2022年6月21日にCloudflareの19のデータセンターのトラフィックに影響を与える障害が発生したようです。 また、この19のデータセンターはどうやら世界中のトラフィックのかなりの割合を扱う拠点だったようです。 ではなぜ、大規模な障害が発生したのかというと、原因はどうやらこれらの重要な拠点の耐障害性を向上させるための変更(ネットワーク設定の変更)を行なったことが起因しているようです。 なので、今回の障害では悪意のある攻撃等ではなかったことになります。 障害が発生した時刻と復旧した時刻 障害が発生した時刻は、2022年06月22日 15:58ごろに発生し、2022年06月22日 16:42ご

    2022年6月21日に発生したCloudflareの大規模障害の原因 - Qiita