ニューヨークで自転車事故にあって救急車で運ばれた
序いつもの水曜日の朝。いつものように愛車にまたがり、歩行者の予測不能な動きに細心の注意を払いながらブルックリンブリッジを越え、車線のある道に出てほっと一安心し、前方に2台の自転車が並走してこちらに向かってくるのを見て、「まあ完全に車線があるところだし周囲にも余裕はあるし、あっちが避けるに決まってる」と思い込んでそのまま自分の車線を直進し、… え？避けないの？？？は？なに？してんのお前？ まったく回避行動をしないでこちらの車線上で逆走を続けた1台と、隣の車線を走る2台との間をすりぬけるような感じになって、すり抜けられた！とおもった次の瞬間、こちらの車線を逆走していたライダーと接触してふっとばされ、左肩から道路に落ちた。 しばらく呆然として、それから何気なく左肩から首にかけて触ってみて、変な出っ張りがあるのに気づいて、「あ、鎖骨折れた」。自転車ロードレースを見ていておなじみになった、fract
システム移行メンテナンスにおける一部時間帯に更新されたデータが消失した原因のご報告 - Mackerel お知らせ #mackerelio
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日
GitLab Live Stream
Working on restoring GitLab.com. FAQ below. * Blog post https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/ * Who did it, will they be fired? Someone made a mistake, they won't be fired. * The audio is too low, can you fix it? No, we're sorry. * Why is the restore so slow? We're limited by the disk speed of a non-production machine. * Size of the DB? 310GB * How long will t
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
ANAシステム障害の原因の発表を聞いたみなさんの反応まとめ
タモ＠＜ハザードマップを再度確認しましょう！＞ @tamosan ANAの件、「中継器」側からの故障シグナルのみでフェイルオーバーするような仕組みだったのでしょうかねぇ だとすると設計考慮不足かと思いますよ(´・ω・`) 2点、3点での監視も必要でしょうねぇ（対策としてそれを実施したようすですが） 2016-03-30 17:22:47
チケットぴあの高額チケット不正購入の可能性についてまとめてみた - piyolog
2014年8月上旬以降、Twitter上でチケットぴあを通じてチケットの不正購入、並びにそれに伴う高額請求が来ているとのつぶやきがされています。まずは気になるつぶやきをまとめます。 公式発表 2014年8月25日現在公式での発表は行われていないが、以下内容が報道されている。*1 6月から現在にかけて不正ログインによる被害が多くなっていることは確か。 これまでと比較して爆発的に増加はしていない。 自社から情報が流出した可能性については否定。 ID/パスワードの使いまわしによる被害拡大の一環との認識。 チケットぴあだけが際立っているわけではない。 不正購入されたとのつぶやき た・たいへん(°Д°) チケットぴあから見に覚えのない購入案内が… しかもクレジットカードでの購入で総額９万？ ぴあのセキュリティどうなってんの？ てかクレジットカードの情報盗まれたのか？ マジ〜(T_T)— yumiri
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
