AppleのApp Storeなど21のサービスが深夜にダウン 午前2時過ぎに復旧
米AppleのクラウドサービスiCloudをはじめとする21のネットワークサービスで、日本時間の3月22日午前1時過ぎから約1時間、障害が発生していた。ステータスページによると問題があったのは午前1時27分～2時30分。 Apple Payとウォレット、iCloud、キーチェーン、iMessage、マップなどで「一部のユーザーに影響しました」となっている（記事末にスクリーンショットを掲載）。本稿執筆現在、Appleからはまだ原因などについての発表はない。 米国では月曜の午後で、小売りシステムもダウンしたようで、Appleの実店舗で従業員が紙の書類で手続きをしている画像がTwitterに投稿されている。 関連記事 iCloudで「機能停止」 一時「Apple Music」なども【復旧済み】 AppleのクラウドサービスiCloudとその関連機能が2月3日の早朝、繋がりにくくなっている。「シス
自社のDB破壊しCEOに身代金要求、freeeが本当にやったクラウド障害訓練の舞台裏 「従業員はトラウマに」
自社のクラウド環境に侵入され、データベースから経営に欠かせないデータを持ち出される。バックアップも消され、データを取り戻したければ、身代金を支払うよう要求される──企業にとって絶対に直面したくない事態の一つだ。しかしこのシチュエーションをあえて再現し、訓練という形で自社のCEOに身代金まで要求した企業がある。クラウド会計サービスを提供するfreeeだ。 freeeは2021年10月、標的型攻撃とランサムウェアを組み合わせたシナリオを基に全社的な訓練を実施。AWS上のDBからデータを盗み出し、バックアップを消した上で、自社のCEOに社内SNSを通して身代金を要求したという。訓練を主導したのは、製品やサービスのセキュリティ向上を目指す社内組織「PSIRT」だ。 訓練を実施した背景には、情報システム部などのIT部門だけでなく、経営層まで巻き込みたい考えがあったという。同社のPSIRTが取り組んだ
昨今の発達障害マンガについて
十歳の時に弟とセットで発達障害診断されたまだギリアラサー女性の増田です。 昨今の発達障害系エッセイマンガ読んでるともやもやするので文章にする。 かれこれ二十年ほど前、弟がいかにもなアスペ（今はASDか）だったので、母が大きい病院に連れて行ったら、何となくついていった私も 「お姉ちゃんのほうもガチめのアスペっぽいんで検査してください」 みたいなこと言われて検査したらバリバリ文句なしのアスペだった。 しかも「この先普通に進学できると思わないでください」とか言われるレベルだった。 だったけど、私は幸いというべきか ・感覚過敏じゃなくて感覚鈍麻（過敏の方がフォーカスされがちだけど鈍麻も少なからずいる） ・とにかくぼーっとしてる方のアスペ（注意力散漫）だったので、多動がなかった ・私の世代が比較的穏やかかつオタク（陰キャ）多めだったのでいじめにあわず、コミュニケーションの問題があまり目立たなかった
みずほ銀行窓口業務ストップの真相、DC切り替えをためらい障害が長期化
みずほ銀行で2021年8月20日、営業店の窓口業務が全面停止するトラブルが発生した。前日の19日午後8時53分ごろに営業店端末と勘定系システムをつなぐサブシステムで、データベース（DB）サーバーがディスク装置の故障をきっかけに停止したためだ。待機系DBサーバーへの切り替えも失敗、副データセンター（DC）に処理を切り替えた。副DCへの切り替えに着手するまで11時間超を要し、業務開始に間に合わなかった。 みずほ銀行で2021年8月20日、全463店舗で営業店端末や店頭のタブレット端末が使用不能になった。午前9時の開店から午前9時45分までは全ての店頭取引ができなくなり、その後も午前11時58分まで融資や外国為替（外為）の一部取引ができなくなった。営業店端末などと勘定系システム「MINORI」をつなぐサブシステム「業務チャネル統合基盤」が前日の8月19日午後8時53分ごろに停止したためだ。 業務
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
ロギングベストプラクティス - kawasima
#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設
8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話 - Make組ブログ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
Google Cloud、複数のファイバケーブルで物理的な損傷によるネットワーク障害。米東1リージョンで
Google Cloud、複数のファイバケーブルで物理的な損傷によるネットワーク障害。米東1リージョンで Google Cloudの米東1リージョン（サウスカロライナ）で、太平洋標準時7月2日午前7時55分（日本時間7月2日午後11時55分）頃から断続的にネットワーク障害が発生。Google Cloud NetworkingとLoad Balancingに影響が出ています（Googleの報告1、報告2）。 報告によると、この障害の原因はファイバケーブルの物理的な破損にあるようです。 7月2日7時55分（太平洋標準時）における最初の報告で、米東1リージョンのすべてのゾーンにおいて外部との接続が失われたと説明されています。 The Cloud Networking service (Standard Tier) is experiencing external connectivity los
メンテナンス・障害情報・機能追加｜さくらインターネット公式サポートサイト
2018年09月06日掲載 障 害 発 生 の お 知 ら せ さくらインターネット株式会社 平素よりさくらインターネットをご利用いただき、誠にありがとうございます。 本日、ご提供サービスにおきまして、以下の通り障害が発生いたしました。 ご利用中のお客様には大変ご迷惑をおかけいたしましたことを深くお詫び 申し上げます。 ＜ 記 ＞ 発生日時 : 2018年09月06日03時08分 - 2018年09月06日07時44分 影響範囲 : さくらの専用サーバ 石狩第2ゾーンの一部 以下のIPアドレス範囲に含まれるさくらの専用サーバを ご利用のお客様 153.127.106.* 153.127.107.* 153.127.108.* 153.127.109.* 153.127.110.* 153.127.140.* 153.127.141.* 障害内容 : 一部の電源設備において障害が発生しており
.ioドメイン不調に伴うMackerelの死活監視アラートの誤報の発生とそれに対する対応について - Mackerel お知らせ #mackerelio
Mackerelサブプロデューサーの id:Songmu です。表題の件、ユーザーの皆様には度々ご迷惑をおかけしており大変申し訳ありません。 本件の詳細に関する説明と、今後の対応に関してお知らせいたします。 死活監視のアラート誤報に関して Mackerelでは、mackerel-agentから一定時間メトリック投稿が途絶えた事をもって、サーバーがダウンしたと判断し、死活監視アラートを発報する仕組みになっています。 現在、 mackerel.io ドメインの名前解決が不安定になっております。それに伴い、 mackerel.io ドメインの名前解決が一定期間失敗し、Mackerelへのアクセスが一時的にできない環境において、 mackerel-agent がMackerelへのメトリック投稿をおこなうことができず、Mackerelシステム側でサーバーがダウンしたと判断してしまい、死活監視のアラ
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日 CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない
東商取でシステム障害 夜間取引・清算値公表遅れる - 日本経済新聞
東京商品取引所は27日、夜間取引の開始が遅れるシステム障害が発生した。通常、夜間取引は午後4時30分に開始するが、午後6時15分の開始となった。同日の日中取引の清算値の確定作業も遅れた。東商取は「原因を含めて調査中。清算値の確定
運用監視に必要な知識はOS、コマンド、そしてプログラミング～ゼロからの運用監視設計（後編）。July Tech Festa 2016
運用監視に必要な知識はOS、コマンド、そしてプログラミング～ゼロからの運用監視設計（後編）。July Tech Festa 2016 運用監視の自動化は、複雑化するアプリケーションやサービスに対して効率的かつ確実な運用監視を実現する上で、またコスト削減の意味でも重要な要素になってきています。しかし運用監視の自動化は、どのように考えて実現していけばいいのでしょうか。 （本記事は「正しく運用されているかを評価するのが監視である～ゼロからの運用監視設計（前編）。July Tech Festa 2016」の続きです。） ゼロからの監視設計 ひとつはサービスレベルの定義、もうひとつは非機能要件としてのシステム監視ですね。こういうことは以外と職場でも学校でも教えてくれなかったことです。 なぜかというと、だいたい担当部署によってみているレイヤが違うわけです。物理層を見ているところ、ネットワーク層、あるい
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Twitterで大規模障害が発生 Twitterと連携したサービスやゲームにログインできない状態続く
TechCrunch