タグ

障害に関するharumaki_netのブックマーク (34)

  • 当社サービスへのサイバー攻撃に関するご報告とお詫び | 株式会社ドワンゴ

    {.md_tr}株式会社ドワンゴ 株式会社ドワンゴ(社:東京都中央区、代表取締役社長:夏野剛)は、2024年6月8日付けのニコニコインフォで公表したとおり、6月8日早朝から当社が運営する「ニコニコ」のサービス全般を利用できない状態が続いております。障害は、ランサムウェアを含む大規模なサイバー攻撃によるものであることが確認され、現在サービスの利用を一時的に停止し、被害状況の全容把握と復旧に向け、調査と対応を進めております。 当社は、サイバー攻撃を確認後、直ちに関連するサーバーをシャットダウンするなど緊急措置を実施するとともに、対策部を立ち上げ、被害の全容解明、原因究明およびシステムの復旧対応に総力を上げて取り組んでおります。現時点までの調査で判明した内容および今後の対応について、以下の通りご報告いたします。 ユーザーの皆様、関係者の皆様に、多大なるご迷惑とご心配をおかけしておりますこと

    当社サービスへのサイバー攻撃に関するご報告とお詫び | 株式会社ドワンゴ
  • 江崎グリコの基幹システム移行トラブルについてまとめてみた - piyolog

    2024年4月5日、江崎グリコは基幹システムの切り替え後にシステム障害が発生し、同社や販売委託を受けている一部の冷蔵品の出荷に影響が生じていると公表しました。ここでは関連する情報をまとめます。 障害後緊急対応するも在庫数合わず業務停止 今回システム障害が起きたのは江崎グリコの基幹システムで2024年4月3日の新システムへの移行に伴い発生した。物流、販売、会計などを一元管理するERPパッケージ SAP社製「SAP S/4HANA」で構築されており、「顧客への継続的価値創出を可能にするバリューチェーン構築と経営の迅速な意思決定を目的とした、調達・生産・物流・ファイナンスなどの情報を統合する基幹システム」と同社では説明している。障害原因の詳細は同社から開示されてはいないが、システム障害の問題個所の特定は済んでいる。なおサイバー攻撃によるものではないと取材に答えている。*1 システム障害の影響に

    江崎グリコの基幹システム移行トラブルについてまとめてみた - piyolog
  • 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
  • みずほ銀行窓口業務ストップの真相、DC切り替えをためらい障害が長期化


    202182019853DBDBDCDC11 2021820463使99451158MINORI819853 
    みずほ銀行窓口業務ストップの真相、DC切り替えをためらい障害が長期化
  • AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい


     t-cyrill.hatenablog.jp  2021/02/19 23:20 AWS apne-az1 AWS     23:25  SlackAWSElasticache  AWS20198
    AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい
  • 2020年10月に発生した東京証券取引所のシステム障害についてまとめてみた - piyolog

    2020年10月1日、東京証券取引所はアローヘッドの機器故障によりシステム障害が発生し、終日売買を停止すると発表しました。故障した機器は交換が行われ、取引は翌日再開されています。ここでは関連する情報をまとめます。 機器故障起きるも縮退運用に失敗 障害概要図 アローヘッド内の共有ディスク装置1号機で機器故障が発生した。実際故障したのはサーバー上のメモリ周辺機器とされる。 1号機故障により両現用で稼働していた2号機のみのフェールオーバー(縮退運用)が行われるはずだったが何らかの問題により行われなかった。 共有ディスク装置を使用する相場配信、売買監視のシステムで障害が発生。 障害復旧時に発生する注文データ消失による市場混乱を避けるため当日終日の取引停止の措置を実施。(遮断) フェールオーバー失敗原因は設定ミス フェールオーバーに失敗した理由が特定できたとして10月5日に発表。 障害発生時のフェー

    2020年10月に発生した東京証券取引所のシステム障害についてまとめてみた - piyolog
  • システム障害の本のカット「重大障害時におけるCIOの取組み(悪い例)に「あらゆる闇」が内包されていた…見た人「あれ、俺、なんで泣いてるんだろう」


     @ryota_hnk google New Relicheadtonirvana.hatenablog.com qiita.com/ryota_hnk lapras.com/public/2ZM2JJP
    システム障害の本のカット「重大障害時におけるCIOの取組み(悪い例)に「あらゆる闇」が内包されていた…見た人「あれ、俺、なんで泣いてるんだろう」
  • Webサービスの障害対応のときの思考過程 - ぱいぱいにっき

    起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター

    Webサービスの障害対応のときの思考過程 - ぱいぱいにっき
  • システム障害対応演習を実施した話|NAVITIME_Tech


     Arch Enemy   Web API 
    システム障害対応演習を実施した話|NAVITIME_Tech
  • 無料&オープンソースでシステム障害のレポートを一元化できる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

    無料&オープンソースでシステム障害のレポートを一元化できるNetflix製インシデント管理ツール「Dispatch」
  • ストレージはこわいよ - orangeitems’s diary


     3   1   
    ストレージはこわいよ - orangeitems’s diary
    harumaki_net
    harumaki_net 2019/12/08
    無能と嘲っている連中は自分たちが初めて経験した障害を思い出してみるべき。経験して得た学んでは財産。
  • [無いものの存在]_01: 右足を切断しました|青木彬


      121調 20199712
    [無いものの存在]_01: 右足を切断しました|青木彬
  • AWS大障害の真相、冗長構成の「安全神話」崩壊 - 日本経済新聞


    823AWS65調AWS 
    AWS大障害の真相、冗長構成の「安全神話」崩壊 - 日本経済新聞
  • Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか


    Microsoft AzureDNS Microsoft Azure2019527431035 2019534437353DNS Microsoft AzureOffice 365/Microsoft 365Microsoft Dynamics DNSDNSAzure DNS
    Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか
  • SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告


    SREGmail313Google31311531513320GmailGoogle DriveGoogle PhotosGoogle StorageApp EngineBlobstore APIGoogle GoogleGoogle Cloud Status Dashboard#19002 SRESite Reliability Engineer SRESite Reliabili
    SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告
  • 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のメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した

    GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった:データベースの不整合解消に時間 - @IT
  • 本当は恐ろしい分散システムの話

    分散システムのFault Injectionの話 NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料 https://oss.nttdata.com/hadoop/event/201710/index.html Read less

    本当は恐ろしい分散システムの話
  • もはやランサムウェアとは呼べない「NotPetya(Petya)」の恐怖 (1) 再び世界を襲ったNSAのエクスプロイト | THE ZERO/ONE


    BitcoinEthereumLitecoinBitcoin Cash使    
    もはやランサムウェアとは呼べない「NotPetya(Petya)」の恐怖 (1) 再び世界を襲ったNSAのエクスプロイト | THE ZERO/ONE
  • TechCrunch

    Apple seems to be finally getting serious about infusing generative AI into its products — both internal and external — after announcing a solitary “Transformer” model-based autocorrec

    TechCrunch
  • 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チームが作業にあたっていた。決済システムのサブシステムを構成する数台のサーバーを停止する目的で、特権を認められたチームメンバーが手順書に従ってコマンドを入力したが、コマンド入力にミスがあり、意図したより多くのサーバーを停止させてしまった。他の重要なサブシステムにも影響が広がり、システム全体を再起動しなければならなくな

    Amazon S3の大規模障害は人為的ミスが原因