大規模なブルースクリーン障害 原因の解析が進む（山口健太） - エキスパート - Yahoo!ニュース
7月19日、世界各地のWindows PCが「ブルースクリーン」でダウンしたシステム障害が大きな話題になっています。いったい何が原因だったのか、解析が進んでいます。 ブルースクリーンの原因は？システム障害が起きたのはCrowdStrike（クラウドストライク）による企業向けセキュリティ製品を導入しているWindows PCです。米国の公式ブログや、日本の販売代理店であるマクニカが技術的な背景を説明しています。 実際に起こった現象としては、Windowsが再起動を繰り返すというものですが、これが世界規模で同時に起きたことで多大な混乱を引き起こしています。巻き込まれた人は不運だったというしかありません。 ブルースクリーンはWindowsに昔から組み込まれているエラー画面で、システムを強制的に停止せざるを得ない致命的な状況に陥ったことを示しています。 Windowsのバージョンによって表示内容は
IT人材として押さえたい「サーバ」のイロハ(9) サーバダウンに備えよう - 可用性を高める運用のポイントを解説
企業のITインフラやさまざまなITサービスを実現するうえで「サーバ」は欠かせない存在で、企業が求めるIT人材として知っておきたい必須知識の1つでもあります。 本連載では、「サーバとはいったいどのようなものか？」に始まり、利用方法や種類などの基礎的な知識とともに、セキュリティ対策や仮想化、サーバレスなど効率的にサーバを利用・管理するうえでのポイントといった、情報システム担当者の実務に役立つ話題を紹介していきます。 連載第9回は、キンドリルジャパンの佐藤創太郎さんに、主にオンプレミス環境を想定したサーバダウンを防ぐための可用性確保と復旧のポイントについて解説してもらいます。 サーバの耐用年数はどれくらい? 信頼性を高める方法は? サーバの耐用年数は、「製品の保証期間」で決まります。保証期間内であれば、ハードウェアの故障が起こっても数日で交換してもらえます。一般的に保証期間は3年もしくは5年で、
知って納得、ケータイ業界の"なぜ"(120) KDDIの大規模通信障害から考える、モバイル通信の重要性が高まる時代の“備え”
2022年7月2日深夜に発生したKDDIの通信障害は、完全復旧まで86時間にも及び、コミュニケーションだけでなく社会活動にまで大きな影響を与える非常に規模の大きなものとなった。だがその通信障害の内容からは、KDDIだけでなく携帯電話会社全体で、同様の規模の障害が今後も発生する可能性が十分あり得るようにも感じる。我々はどのような対処をすべきなのだろうか。 KDDIは本当にNTTドコモの教訓を生かせなかったのか? 先の週末に連日報道がなされ、大きな注目を浴びたKDDIの通信障害。2022年7月2日の深夜に発生し、2022年7月5日の15時に完全な回復が確認され、復旧宣言がなされるまで86時間、3日以上にわたってKDDIの通信サービスを利用している人が通話や通信がしづらい状況が続いたというのは、既に多くの人がご存知の通りだ。 KDDIは86時間にわたる大規模通信障害を発生させ、社会的にも大きな影
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
なぜ我々はsession.cookieを変更しなければならなかったのか - BASEプロダクトチームブログ
はじめに こんにちは。バックエンドエンジニアの小笠原です。 今回は、2022年2月18日から2022年3月4日にかけて発生していたこちらの障害に対し私達開発チームが実施した、session.cookieで定義しているCookieのkey名を変更するという影響範囲の大きい対応について、実施に至るまでの経緯や対応過程についてご紹介したいと思います。 ショップオーナー向けに掲載していたお知らせの内容 背景 全ては iOS14.5から端末識別子の取得に同意が必要になったことから始まった ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。 この変更は、端末所有者側から見ると情報の活用範囲を自身で管理できることでよりプライバシーに配慮されるようになった良い変更と言えるでしょう。 一方で、広告出稿側から見た場合は拒否をしたユーザーの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
