江崎グリコの基幹システム移行トラブルについてまとめてみた - piyolog
2024年4月5日、江崎グリコは基幹システムの切り替え後にシステム障害が発生し、同社や販売委託を受けている一部の冷蔵食品の出荷に影響が生じていると公表しました。ここでは関連する情報をまとめます。 障害後緊急対応するも在庫数合わず業務停止 今回システム障害が起きたのは江崎グリコの基幹システムで2024年4月3日の新システムへの移行に伴い発生した。物流、販売、会計などを一元管理するERPパッケージ SAP社製「SAP S/4HANA」で構築されており、「顧客への継続的価値創出を可能にするバリューチェーン構築と経営の迅速な意思決定を目的とした、調達・生産・物流・ファイナンスなどの情報を統合する基幹システム」と同社では説明している。障害原因の詳細は同社から開示されてはいないが、システム障害の問題個所の特定は済んでいる。なおサイバー攻撃によるものではないと取材に答えている。*1 システム障害の影響に
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
みずほ銀行窓口業務ストップの真相、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分ごろに停止したためだ。 業務
AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい
前にも似たようなこと書いたなと思ったけどもう一年半も前のことになるのか t-cyrill.hatenablog.jp ご存知の通り昨日 2021/02/19 23:20頃 AWSにて東京リージョンの一つ apne-az1 にて大規模な障害が発生。多くのAWSを利用していたサービスで影響があった。 そんな私はいつものように アラストリリィ アサルトリリィ ラストバレット というゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。 どうしたんだろうと思っていたら、社内SlackにてAWSを利用しているサービスがたまに応答しなくなる、Elasticacheが切り替わったなどなどの報告が入り、もしかすると面倒ごとかなと思いながら対応することになった。 起きていたこと 既にAWSからも公開されていることであるが、今回は2019年8月に起きた障害と類似するタイプの障害だっ
2020年10月に発生した東京証券取引所のシステム障害についてまとめてみた - piyolog
2020年10月1日、東京証券取引所はアローヘッドの機器故障によりシステム障害が発生し、終日売買を停止すると発表しました。故障した機器は交換が行われ、取引は翌日再開されています。ここでは関連する情報をまとめます。 機器故障起きるも縮退運用に失敗 障害概要図 アローヘッド内の共有ディスク装置1号機で機器故障が発生した。実際故障したのはサーバー上のメモリ周辺機器とされる。 1号機故障により両現用で稼働していた2号機のみのフェールオーバー（縮退運用）が行われるはずだったが何らかの問題により行われなかった。 共有ディスク装置を使用する相場配信、売買監視のシステムで障害が発生。 障害復旧時に発生する注文データ消失による市場混乱を避けるため当日終日の取引停止の措置を実施。（遮断） フェールオーバー失敗原因は設定ミス フェールオーバーに失敗した理由が特定できたとして10月5日に発表。 障害発生時のフェー
Webサービスの障害対応のときの思考過程 - ぱいぱいにっき
起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター
システム障害対応演習を実施した話｜NAVITIME_Tech
こんにちは、ネコ派メタラーです。ナビタイムジャパンで地点検索基盤の開発マネジメントを担当しています。好きなバンドは Arch Enemy です。 システム運用に関わる人であれば、「システム障害」というと耳が痛い方が多いかと思います。システム障害は起こさないに越したことはないですが、万が一システム障害が発生したとき、その行動選択はサービスの信頼性を大きく左右することになります。 迅速に復旧させることはもちろんですが、適切な情報公開によってユーザーの不安を払拭するといったコミュニケーションも重要なポイントです。しかし、緊急事態というプレッシャーを受けながら最適な行動を選択することは容易ではありません。 私が所属しているチームでは、Web API サーバソフトウェアから全文検索ミドルウェアまで含めた開発・運用を行っており、幅広いトラブル対応スキルが必要になります。トラブル対応のスキルを持ったベテ
無料＆オープンソースでシステム障害のレポートを一元化できるNetflix製インシデント管理ツール「Dispatch」
システムの保守・運用を行うインフラエンジニアにとって、障害対応は最も責任のある仕事のひとつであり、障害の監視や通知に関するツールは「PagerDuty」や「Zabbix」が有名です。そうした障害対応を助けてくれるツールとして、Netflixが無料のオープンソースソフトウェア「Dispatch」を公開しました。 Introducing Dispatch - Netflix TechBlog https://netflixtechblog.com/introducing-dispatch-da4b8a2a8072 About - Dispatch https://hawkins.gitbook.io/dispatch/ Netflix Dispatch - Reviews, Pros & Cons | Companies using Netflix Dispatch https://stack
ストレージはこわいよ - orangeitems’s diary
ある夜起こったどこかの会社の話 夜も更けた午前3時半ごろの思い出。 オンプレミスでの仮想基盤。いくつものシステムが動いていたのですが突然、この時間に複数のシステムエラーを感知。 電話で連絡が来るようになっていたのですが、あっちもこっちもそっちもどっちもアラートなので何が何だかわからなくなります。 運用設計なんて、特定のシステムがエラーとなったときのことしか考えられていないので、十も二十も同時にアラートになったら破綻します。電話連絡ったって電話は１つしかないので、担当者にはつながらなくなります。 私は運用の場面ではリーダーだったので、メンバーからエスカレーションを受けます。あっちも、こっちも、そっちもエラーですと。何が起こってるの？、わかりません。 眠気なんて一気に吹っ飛ぶのですが、一方で世の中の終わりを悟ります。 例え、この窮地を切り抜けたところで、たくさんの恒久対応までの道のりと、謝罪行
[無いものの存在]_01: 右足を切断しました｜青木彬
既にお知らせをした方もいらっしゃいますが、実は右足を切断する手術をしました。 青木はなんか足が悪いらしいくらいの認識のかたがほとんどで、中にはそんなことも知らない人もいると思いますが、右足には人工関節が入っており、障害者手帳も発行される身体障害者です。 元々、12歳の誕生日に骨肉腫が見つかり約1年間の抗がん剤治療後、右足を人工関節にする手術をしていました。その後は数度の手術をしつつも再発はなく順調に生活していました。 2019年9月に夜道でつまずいたことで人工関節を入れた右足が激しく痛み、ちょっとヤバイと思い近所の病院に駆け込んで紹介状を書いてもらい、約7年ぶりに大学病院に行きました。 12歳の頃から仲の良かった医師に診察してもらったところ、つまずいたことは問題なかったのですが、数年前から感染症が進行しており、その影響で脆くなっていた大腿骨に人工関節が埋没し始めていて良い状態ではないとのこ
![[無いものの存在]_01: 右足を切断しました｜青木彬](https://cdn-ak-scissors.b.st-hatena.com/image/square/65cc979d2e0b630e822215306d01043f2afb6439/height=288;version=1;width=512/https%3A%2F%2Fassets.st-note.com%2Fproduction%2Fuploads%2Fimages%2F16554339%2Frectangle_large_type_2_dad182856a6a01f1d776f0a6a6eb5ded.png%3Ffit%3Dbounds%26quality%3D85%26width%3D1280)
Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか
Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか Microsoft Azureは、2019年5月2日午後7時43分から午後10時35分まで（日本時間 2019年5月3日午前4時43分から午前7時35分まで）の約3時間、DNSの名前解決に問題が発生。 ほぼ全世界的に、Microsoft AzureをはじめOffice 365/Microsoft 365やMicrosoft Dynamicsなど同社サービスに対する接続ができなくなるという大規模な障害を起こしました。 この大規模障害の原因は、同社サービス用のDNSのメンテナンス作業のミスが原因だったと発表されました（中間報告の段階では既存のDNSからAzure DNSへのマイグレーション作業に失敗したと報告されていました。現在の報告では計画メンテナンス作業での失敗だとされ
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告 3月13日の11時53分から15時13分（いずれも日本時間）までの3時間20分のあいだ、GmailやGoogle Drive、Google Photos、Google Storage、App EngineのBlobstore APIなどGoogleの広範囲なサービスで一部の機能が利用できなくなる、あるいは遅延が発生するなどの障害が発生しました。 その原因と対策について、Googleが「Google Cloud Status Dashboardのインシデント#19002」として報告しています。 報告では障害の原因が、ストレージ内のリソースを削減しようとしたSRE（Site Reliability Engineer）による構成変更にあったと説明。 SRE（Site Reliabili
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 - ＠IT
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータ管理データベースの不整合を引き起こし、復旧に時間を要したという。 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した
もはやランサムウェアとは呼べない「NotPetya（Petya）」の恐怖 (1) 再び世界を襲ったNSAのエクスプロイト | THE ZERO/ONE
ミスティーノは、仮想通貨でも遊べるオンラインカジノです。仮想通貨での入金には、Bitcoin、Ethereum、Litecoin、Bitcoin Cashなどが使用できます。また、出金も仮想通貨で行うことができます。 また、ミスティーノでは、スロットやテーブルゲーム、ライブカジノ、ポーカー、ビデオポーカー、バカラ、サイコロなど、様々なオンラインカジノゲームが楽しめます。さらに、スマートフォンやタブレットでのプレイも可能ですので、いつでもどこでもカジノゲームを楽しむことができます。 実際にミスティーノで遊んでみた感想 ミスティーノでは、新規登録や入金などに応じて、さまざまなボーナスが提供されています。 新規登録ボーナスとしては、入金不要で手に入る「フリースピン」があります。また、入金ボーナスとしては、入金額に応じた「マッチボーナス」が提供されることがあります。さらに、プレイヤーのレベルが上が
Amazon S3の大規模障害は人為的ミスが原因
米Amazon.comのクラウド事業Amazon Web Services（AWS）は「Amazon Simple Storage Service (S3）」サービスで発生した大規模障害に関する調査報告を現地時間2017年3月2日までに公表し、人為的ミスが原因だったことを明らかにした。 S3の障害は、米バージニア州北部の「US-EAST-1」リージョンで太平洋標準時間2月28日午前9時37分に発生した。 AWSの報告によれば、当時、S3の決済システムの問題を修正するために、S3チームが作業にあたっていた。決済システムのサブシステムを構成する数台のサーバーを停止する目的で、特権を認められたチームメンバーが手順書に従ってコマンドを入力したが、コマンド入力にミスがあり、意図したより多くのサーバーを停止させてしまった。他の重要なサブシステムにも影響が広がり、システム全体を再起動しなければならなくな
NTT、ネットワーク障害の原因を推定するAI技術を開発。従来のネットワークエンジニアによる分析と切り分けを不要に
NTT、ネットワーク障害の原因を推定するAI技術を開発。従来のネットワークエンジニアによる分析と切り分けを不要に NTTは、ネットワーク障害時にネットワーク機器などから発生するさまざまな警告などを分析し、障害の原因を分析、推定するAI技術を開発したと発表しました。 NTTによるとこのAI技術は、ネットワーク障害の対応履歴などを基にネットワーク機器などからのアラームと真の障害原因を教えていくことで、障害の原因を推定するルールそのものを自動的に作り出せるというもの。そしてこのAI技術によって、これまでネットワーク障害時に技術者が行っていた障害の切り分けや分析作業をAIが実行できるようになるとのこと。 本技術を用いた障害原因推定がシステム化されると、これまで数時間から数日かかることもあった分析作業を数秒程度に短縮することができ、スキルフリーで迅速なネットワーク障害対応が可能となります。 （プレス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システム障害の本のカット「重大障害時におけるCIOの取組み（悪い例）に「あらゆる闇」が内包されていた…見た人「あれ、俺、なんで泣いてるんだろう」
AWS大障害の真相、冗長構成の「安全神話」崩壊 - 日本経済新聞
本当は恐ろしい分散システムの話
TechCrunch
