OpenAI co-founder and Chief Scientist Ilya Sutskever is leaving the company
Engadget | Technology News & Reviews
OpenAI co-founder and Chief Scientist Ilya Sutskever is leaving the company
日本電子計算(JIP)
当社がサービスを提供する自治体専用IaaSサービス「Jip-Base」に12月4日(水)10時56分頃から発生している障害のために、本日12月9日(月)時点においても「Jip-Base」のサービスの大半がご利用いただけない状況が継続しております。 ご利用のお客様、また本障害の影響がある自治体の住民の皆様には、引き続きご不便をおかけしており、誠に申し訳ございません。 本障害発生後、IaaSサービス「Jip-Base」の全面復旧を目指して全力を挙げて作業を進めてきました。ストレージのファームウェア不具合が引き起こしたハードウェアの故障は修復したものの、 その後の動作確認において各種データへのアクセス処理が正しく動作しない事象が判明し、現時点でもその解消に至っておりません。そのため、当初計画の大幅な見直しが必要であると判断しています。 現在、「Jip-Base」のサービス復旧計画の再策定を行って
NTTデータ子会社のクラウドが壊滅、ストレージのバグで戸籍や税務などのデータ全消失 : 痛いニュース(ﾉ∀`)
NTTデータ子会社のクラウドが壊滅、ストレージのバグで戸籍や税務などのデータ全消失 1 名前：ベスタ(茸) [US]：2019/12/05(木) 17:18:57.47 ID:yztuQHN80 日本電子計算株式会社（通称：JIP）とは、NTTデータの子会社、いわゆる「デー子」である。 概要 1962年に日本証券金融株式会社の電算室が独立し「日本電子計算」として分社化するかたちで設立された。 2012年にNTTデータにより公開買付（TOB）が行われ約100億円で買収された。 この買収は「NTTデータは銀行業には強いが証券業には弱い」というのを補うためだとしている。 2019年12月4日午前11時ごろ、同社が運営するクラウドサービスが吹っ飛び、その上で動く全国の自治体システムも吹っ飛び、全国約50の自治体で戸籍管理や税務処理、医療保険、図書館などのデータが消失した。 2019年12月4日午後
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？ 今年、2019年5月20日から3日間にわたりスペイン バルセロナで開催されたKubeCon＋CloudNativeCon Europe 2019の基調講演では、SpotifyがミスによってKubernetesのクラスタを消去してしまった経験を振り返るという非常に興味深いセッション「Keynote: How Spotify Accidentally Deleted All its Kube Clusters with No User Impact - David Xia」（基調講演：SpotifyはいかにしてKubernetesクラスタの全削除というミスにもかかわらず顧客への影響を引き起こさなかったのか？）が行われました。 障害が起こることをあらかじめ計画とし
ソフトバンク大規模通信障害の原因:Geekなぺーじ
2018年12月6日、ソフトバンクのネットワークにおいて、4時間25分にわたり約3060万回線の利用者に影響を及ぼす通信障害が発生しました。 ソフトバンクおよびワイモバイルの4G(LTE)携帯電話サービス、「おうちのでんわ」、Softbank Air、3Gサービスなどが影響を受けました。 この障害は、EricssonのMME内部にハードコーディングされた証明書が期限切れになったため、SGSN-MME(Serving GPRS Support Nodex - Mobility Management Entity)が再起動を繰り返してしまったのが原因です。 ただ、証明書が期限切れになることで、なぜ大規模な通信障害に繋がってしまうのかが良くわかりませんでした。 どのような設計をしたら、証明書が期限切れになったことで通信機器が再起動を繰り返すような状況になるのか、昨年段階では、いまいち理解できなか
複数のクレジットカードで決済できないトラブル | NHKニュース
２日夜、クレジットカードの決済システムに障害が起き、カードの決済ができなくなるトラブルが起きました。このシステムは複数のカード会社が利用しているということで、商品の購入などに広く影響が出ているものとみられます。 会社によりますと、カード決済のシステムを運営している「日本カードネットワーク」のシステムに何らかの障害が起きたということです。 「日本カードネットワーク」は、複数のクレジットカード会社が共同で設立した会社で、小売店などの加盟店とカード会社との間で決済データをやりとりするシステムを運営しています。 ＪＣＢによりますと、この会社のシステムは複数のカード会社が利用しているということで、クレジットカードを使った商品の購入などに広く影響が出ているものとみられます。
Cisco Catalyst のTDR試験コマンドでポート故障を遠隔診断する - miyalog
忙しい人向けサマリ リンク障害は現地での物理切り分けしかできずとてもつらい test cable-diagnostics tdr コマンドの結果が Fail もしくは Not completed になったら自装置のポート故障と判断できることを発見 判定率50%、誤検知率0%。範囲は狭いが信頼性が高く大変有用で障害対応時間が大幅短縮 こんにちは。とある通信会社の委託で壊れたルーターを取り替えるだけの簡単なお仕事をしている夜勤作業員です（エンジニアじゃないよ）。ふと思い出したので、私が新入社員のときに初め取り組んだ業務改善のお話をしたいと思います。 地味に面倒なリンク障害の切り分け %LINK-3-CHANGED: Interface GigabitEthernet0/1 changed state to down %LINEPROTO-5-UPDOWN: Line protocol on I
スマートニュースにおける Incident との向き合い方 - SmartNews Engineering Blog
はじめに Site Reliability Engineering チームの Engineering Manager 尾形(@nobu666)です。考えてみたら SRE チームに関してこの Blog でネタにしたことがなかったことに今更気づいてしまいました。UZABASE さん主催の SRE Lounge #3 でも少し触れたのですが、今回は Incident への対応から、Report の書き方、そしてその Review について紹介しようと思います。 Incident Incident Review は障害の振り返り会のことを指します。ポストモーテムということもあります。その前に、そもそも Incident とはなんでしょうか。会社によって定義は様々だと思いますが、弊社においては「ユーザ、あるいは顧客(広告主であったり媒体社であったり)に直接的な影響が出た障害」を Incident と
[4 月 15 日更新] 3 月 31 日夜間から発生した東日本データセンターの障害についての原因調査報告書 (RCA) の抄訳 | Microsoft Docs
[4 月 15 日更新] 3 月 31 日夜間から発生した東日本データセンターの障害についての原因調査報告書 (RCA) の抄訳 04/03/2017 2 minutes to read この度は、2017 年 3 月 31 日に発生した弊社東日本データセンターにおける障害により、Microsoft Azure を利用した貴社業務に多大なるご迷惑をおかけしましたことを、深くお詫び申し上げます。 弊社にてデータセンター施設における原因調査を完了いたしました。以下に、4 月 15 日に公開された、原因調査報告書 (RCA) の更新版の日本語抄訳をご案内いたします。 RCA の原文につきましては、Azure の状態の履歴 (https://azure.microsoft.com/ja-jp/status/history/) をご参照ください。 インシデント情報 インシデント発生日時: 2017
【会見詳報】ANA障害の原因判明、「世界4例のスイッチ故障がきっかけ、対応も遅れた」
全日本空輸（ANA）は6月13日夕方、国土交通省で記者会見を開き、5月末に国内線システムで発生させた大規模障害の原因について報告した。会見に臨んだANAの長瀬眞（ながせ・しん）専務取締役執行役員は「障害発生からログの分析を続けてきた。このような事態が起こらぬよう再発の防止に努め、信頼の回復に努めたい」と述べ、IT推進室長の佐藤透執行役員が詳細を説明していった（写真1）。 障害が起こったのは、旅客の予約・搭乗手続きや手荷物管理をするチェックイン・システムのうち国内部分。27日未明から朝にかけて処理能力の低下が深刻となり、羽田空港にはチェックインを待つ乗客であふれかえった。結局、羽田では午後3時頃から同6時まで発便をすべて欠航させる羽目に陥った。 原因を作ったのは、チェックイン端末をつなぐためのネットワーク機器だった。障害前日の26日午前9時。朝から2系統あるうち1系統のスイッチが障害の兆候を
DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3
はじめに データセンタ障害の話題がちらほら流れておりますが、その中で見かけた「データセンタでそんな障害あったら意味ねえじゃん」みたいなコメントにちょっと引っかかるところがありまして。まあ確かに電源の二重化云々とかいろいろ災害やトラブルに対する対策はしてますよ。してますけど、でもデータセンタ・オーダーの障害とかも実際あるんですよね。落ちるときは落ちるんですよデータセンタだろうと。信頼性は高いけど100%じゃない。 ということで、じゃあ過去どんな事例があったのか、ざっと事例を挙げてみようと思いました。基本的には過去の私のツイートとかはてブとかネットをざーっと検索して出てくるものを取り上げています。「データセンタ使ってるからオールオッケー」みたいな話ではなくて、その上で・さらにこういうこともあるんだ、という話を見るのに参考にしてもらえれば良いかと思います。 なお、ここで取り上げている事例は、特定
GMO、先週の24時間にわたるサービス障害時にはデータセンター内の約12％が電源喪失。変圧分電盤故障が原因の可能性。監視体制の強化など対策
先週末、2016年1月16日から17日にかけて、GMOインターネットが提供するレンタルサーバやドメイン名登録などのサービスで管理画面が表示できなくなるなどの障害が約24時間にわたり発生しました。 GMOインターネットはWebサイトで影響の範囲や復旧状況などを報告、それによると障害の影響範囲は、お名前.com、レンサバ.comなどに加え、ConoHa byGMO、GMOアプリクラウドなどクラウドサービスまで広範囲に渡っています。 また、障害の原因は「データセンター内における電源設備の一部故障」とされました。 24時間という長時間かつ広範囲に発生した障害の実態はどうだったのか、また原因とされた電源設備の一部故障とはどのようなものだったのか、GMOインターネットの発表は詳細部分について触れられていなかったため、PublickeyではGMOインターネットに対して取材を申し込みました。 GMOインタ
通信ケーブルを工事で誤って切断 ネットが不通に NHKニュース
千葉県市川市で１６日、道路の工事中に地中にあるＮＴＴの通信ケーブルが誤って切断され、インターネットの高速通信など１９００余りの回線が不通となっています。 全面復旧は早くても１７日夕方になる見込みだということです。 ＮＴＴ東日本によりますと、１６日午前、千葉県市川市東大和田で、地中にあるＮＴＴの通信ケーブルが、道路工事をしていた作業員によって誤って切断されました。 このため、周辺の市川市大洲や大和田、それに田尻などを含め、インターネットの高速通信や加入電話など合わせて１９００余りの回線が不通となっています。 ＮＴＴ東日本がケーブルをつなぎ直す復旧作業を急いでいますが、全面復旧は早くても１７日夕方になる見込みだということです。
[Failure teaches success] データの持ち方を失敗した - Rejasupoem
社内には障害が起こったりすると、次回失敗しないように "Failure teaches success" っていう知見を蓄積するシステムがあるのだけど、この度 プライベートで書いてるアプリ で障害を起こしてしまったので、知見をブログに書くことにしました。 概要 今日の夕方にmiyagawaさんからAftershowが表示されないと連絡をいただきました。 発生原因 アプリ内でのデータの持ち方にいろいろ問題がありました。 Rebuild.fm for AndroidではEpisodeは端末のsqliteに保存していて、ActiveAndroidで読み書きしていましたが、リスト表示するために何かのカラムでソートする必要があったのだけど、日付は "Jun 15 2014" みたいに入ってくるからソートしづらいなと思って、urlを見てたら "http://rebuild.fm/10" みたいにスラッ
Dropboxが2日以上ダウン。原因はメンテナンス用スクリプトのミス
オンラインストレージサービスのDropboxが、米国時間1月10日の午後から約2日間にわたって障害を引き起こしていました。直接の原因は、OSをバージョンアップするために実行したメンテナンス用スクリプトにバグがあったことです。 障害の状況を時系列で追いつつ、原因についての報告を見てみましょう。 約48時間続いた復旧作業 障害の状況報告については、Dropbox Tech Blogの「Dropbox Status Update」でまとめられています。ポイントごとに引用し、訳しました。 障害発生が認識されたのは、米太平洋時間の午後6時40分です。後になって分かるのですが、この日の5時半に障害の原因となったメンテナンスが始まっています。それから1時間後にDropboxのダウンが発覚します。 1/10 at 6:40pm PT: We are aware that the Dropbox site
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ただならぬ空気を感じる」年末年始の3日間でシステム更新予定だった無印良品ネットストア、サービス再開できず"2020年1月上旬"と未定に
12日夕方からauでメール障害