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

みずほ銀行で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分ごろに停止したためだ。 業務

2021年2月28日、みずほ銀行でシステム障害が発生し、全国で同行のATMが利用できなくなる、キャッシュカードが取り込まれたまま戻ってこないなどのトラブルが発生しました。ここでは関連する情報をまとめます。 取り込まれ戻ってこないキャッシュカード みずほ銀行サイト上に掲載されたシステム障害発生の案内障害が発生したのは2021年2月28日11時頃。障害により各地で生じた影響は以下が報じられるなどしている。なお、法人向けに提供されるサービスでは今回のシステム障害による不具合は確認されていない。*1 障害発生から30時間後に全面復旧をした。 みずほ銀行の自行ATM5,395台の内、54%にあたる2,956台が停止し(2月28日19時40分頃時点)、預金引き落とし等が出来なくなった。*2 台数はその後訂正され、最大4,318台が停止していたことが明らかにされた。 *3 障害発生中は、ATMよりキャッ

りそな銀行は20日、同日昼前に発生したシステム障害について、午後2時25分ごろに復旧したと発表した。障害が起きていた間は他の金融機関の口座への振り込みができない状態だった。 りそな銀によると、インターネットバンキングや自動現金出入機(ATM)、店舗窓口など、すべてのシステムで他行口座に振り込めない状態になっていたという。グループ内の埼玉りそな銀、近畿大阪銀には、りそな銀からの振り込みはできていたとしている。行内でシステム状況を監視している際にエラーを検知し、障害が判明した。 現金引き出しなど他の取引は通常通りできていたという。(福山亜希)

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のメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した

※2018/7/10 15:00 概ね復旧したとのこと 概要 ソフトバンク子会社のファーストサーバーが運営するクラウド型マネージドレンタルサーバー「Zenlogicホスティング」が、緊急メンテナンスのため、全サービスを最長60時間停止すると発表しました。 状況をまとめます。 経緯 2018年6月19日(火)より、ストレージサーバーの高負荷により、サービスが高負荷状態となる障害が断続的に発生していた模様です。 6月19日より一部のお客様で発生している高負荷障害に関するお詫びとお知らせ |Zenlogicサポートサイト[ファーストサーバ] 要約すると、 ・一部ログの出力内容変更 → 効果なし ・一部サーバーの入れ替え → 効果なし ・ストレージシステムの緊急増強 x 3回と設定値変更 → 効果なし ・ストレージシステムの増強メンテナンス → 効果なし ・ストレージシステムの設定最適化 → 効果

ING銀行の基幹データセンター、消防訓練で消火ガス噴射の衝撃音が大量のハードディスクとサーバを破壊。ATMや決済サービスが停止に オランダに本社を置く大手金融機関INGの基幹データセンターで、消防訓練のため消火ガスの噴射をしたところ予想以上に大規模な衝撃音が発生。大量のハードディスクやサーバが故障したと報道されています。 Fire drill knocks INGbank's data centre offline - BBC News INGBank pays back fees to clients affected by system crash in Romania A Loud SoundJust Shut Down aBank's Data Center for 10 Hours |Motherboard これにより9月10日土曜日の朝から夜まで、同社のATMやカード

2016年8月22日頃から、日本の複数サイトで接続し難い、あるいは出来ないといった事象が確認されています。ここでは関連情報をまとめます。 サーバー(Webサイト)への接続等で障害発生しているサービス、サイト 各サイトのTwitter等での発表をまとめると次の通り。 障害発生元 発生原因(運営元発表抜粋) さくらインターネットDoS攻撃、あるいは攻撃と思われる技術評論社 サーバへのDoS攻撃が検知されたことを受け,サービスが提供できない状態 スラド DDoS攻撃の影響はてな さくらインターネットDNSサーバー障害に起因 したらば掲示板 ネットワーク障害 ふたば★ちゃんねる サーバ会社よりDoS攻撃との報告小説家になろう 上位回線の管理会社よりDos攻撃を受けているとの連絡 OSDN DDoS 攻撃の影響 Feeder 全サーバがDDoS攻撃を受けており、サービスをご提供できない状態

リンク ネットショップ担当者フォーラム 閉鎖状態の「ニトリネット」が6/23にサイト運営を再開、不具合の主因はCPU不足 | ネットショップ担当者フォーラム 6月17日から自社ECサイト「ニトリネット」の運営が止まっていたニトリは6月23日、午前10時にリニューアルサイトを公開した。 リンク www.nitori-net.jp 【ニトリ】公式通販 家具・インテリア通販のニトリネット ニトリ公式通販 家具・インテリア通販のニトリネット オンライン・ショップ。お、ねだん以上。ニトリの公式通販サイトです。収納・ベッド・ソファなどの家具、寝具・カーテン・ラグなどのインテリアを販売。7,000円以上お買い上げで送料無料!店舗共通のメンバーズカードでポイントもたまります。

厚生労働省は2014年7月22日、同日9時20分頃から公共職業安定所(ハローワーク)の求人情報検索システムで障害が発生していると発表した。同日17時時点では障害の原因は不明で、復旧のメドは立っていない。 同省職業安定局労働市場センター業務室の説明によれば、同省は全国に約1000カ所あるハローワークに合計約2万1000台の求人情報検索用端末を設置しており、求職者が利用できるようにしている。求職者が検索条件を入力すると、通常は2秒程度で結果が表示される。だが同日朝から、数十秒後に検索結果が表示されたり、そのままエラーになって検索結果を閲覧できなかったりする現象が起きている。 ハローワークの検索システムは7月18日までは正常に動作していた。同省は19日からの3連休を使って、求人情報管理用サーバーのリプレースを実施したという。端末や検索画面の変更は行っておらず、サーバだけを入れ替えた。その後22日

オンラインストレージサービスのDropboxが、米国時間1月10日の午後から約2日間にわたって障害を引き起こしていました。直接の原因は、OSをバージョンアップするために実行したメンテナンス用スクリプトにバグがあったことです。 障害の状況を時系列で追いつつ、原因についての報告を見てみましょう。 約48時間続いた復旧作業 障害の状況報告については、DropboxTechBlogの「Dropbox Status Update」でまとめられています。ポイントごとに引用し、訳しました。 障害発生が認識されたのは、米太平洋時間の午後6時40分です。後になって分かるのですが、この日の5時半に障害の原因となったメンテナンスが始まっています。それから1時間後にDropboxのダウンが発覚します。 1/10 at 6:40pm PT: We are aware that the Dropbox site

KDDIは2013年4月25日、同社のiPhone、iPad、iPad miniにおいて「Eメールリアルタイム送受信サービス」が4月16日から19日にかけて利用できない、または利用しにくい状況になった、通信障害(関連記事)についての説明会を開いた。(写真1) 今回の通信障害は、大きく以下の三つの事象が起こった。(1)4月16日の0時35分から1時間6分の間、全国で最大200人のサービスが利用できない状況、(2)同日8時8分から5時間21分の間、全国で最大288万人のサービスが利用できない状況、(3)同日13時29分から2日と13時間25分の間、全国で最大127万人のサービスが利用しづらい状況、およびカレンダーやアドレス帳などの情報が表示できない状況--である。 長期にわたった障害のきっかけは認証サーバー群のバージョンアップ 一連の障害は、同社が「2013年夏にも導入予定の新サービスのために

出典:日経コンピュータ 2012年10月11日号 (記事は執筆時の情報に基づいており、現在では異なる場合があります) サーバーやネットワークの冗長化は情報システムの信頼性を高めるための常套手段である。しかし、冗長構成を組んだからといって安心はできない。障害発生時、本番系から待機系への切り替えがうまくいかないケースが後を絶たないからだ。なぜフェイルオーバーに失敗するのか。有効な自衛手段はあるのか。事例を基にひも解いていく。 2012年、東京証券取引所は取引停止につながる大規模なシステム障害を二度引き起こし、金融庁から業務改善命令を受けた。東証の取引システムのようなミッションクリティカルな情報システムは、サーバーやネットワークなどを冗長化している。二度の障害はいずれもハードウエア故障が発端。本来、何事もなく本番系から待機系に自動的に切り替わり、サービスを継続できるはずだった。ところが、二度とも

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く