多摩都市モノレールは2018年7月13日、社内向け業務システムがサイバー攻撃を受け、ファイルにアクセスできない状態に陥ったと公表した。ランサムウエアに感染したとみられる。7月17日時点で復旧には至っていない。
By Ken Teegardin カナダ政府は2008年、部門の人員コストを削減するために給与計算部門を廃止し、IBMから給与計算システム「Phoenix Pay System」を導入しました。しかし稼働したシステムは正常に職員たちの給与を計算せず問題となり、事態を終息させるために現カナダ政府が約10億カナダドル(約820億円)を投入する事態にまで発展しています。 Canada to Scrap IBM Payroll Plan Gone Awry Costing C$1 Billion - Bloomberg https://www.bloomberg.com/news/articles/2018-03-01/canada-to-scrap-ibm-payroll-plan-gone-awry-costing-c-1-billion IBMからPhoenix(フェニックス)を導入する事業
アルミ建材大手の文化シヤッターが、販売管理システムの開発が頓挫した責任は委託先の日本IBMにあるとして、約27億4000万円の損害賠償を求めて日本IBMを提訴していたことが、日経コンピュータの取材で明らかになった。 文化シヤッターは2017年11月に東京地方裁判所へ訴訟を提起した。同社は2017年度第2四半期決算(2017年7~10月)で、販売管理システムの開発継続断念に伴う17億4500万円の特別損失を計上済み。同システムの開発委託で日本IBMに支払った費用などの返還を求める。 文化シヤッターが既存の販売管理システムを刷新するプロジェクトを始めたのは2015年3月のことだ。文化シヤッターは日本IBMに提案依頼書(RFP)の作成を委託。そのRFPに基づき複数のITベンダーから提案を受けたうえで、日本IBMをシステム構築の委託先として選定した。 日本IBMの提案は、販売管理システムの構築にE
前々回の記事『理想の働き方改革より現場の業務改善を 〜 現実的で効果的な「業務ハック」のはじめ方』では、業務改善とシステム化を一緒にやってしまう「業務ハック」というコンセプトについて書いた。 そして、今週末には業務ハックの初の勉強会が開催される。おかげさまで好評なため、大阪でも開催することに。(業務ハック勉強会@東京、業務ハック勉強会@大阪) 今回の記事では、そんな「業務ハック」に取り組む職業「業務ハッカー」、すなわち業務改善とシステム化を一緒にやってしまう仕事について書いた。 業務改善とシステム化を兼業する「業務ハッカー」の土壌 「業務ハック」では、現行業務の分析と見える化を行い、ボトルネックを発見し、もっとも効果的な部分から小さく始めていくことを特徴としている。そして、なんでもかんでも作るのではなく、便利なツールやプラットフォームを駆使して、もっとも費用対効果の高いところだけをプログラ
Hadoopの時代は終わった、という言説をたまに見かけるようになりました。 もちろん終わってなどいません。しかし、Hadoopとその取り巻く環境が変化したのは事実です。 本記事では、この変化が何なのかを明らかにし、その上で、なぜHadoopの時代は終わったという主張が実態を正しく表していないのかを説明していきます。 DISCLAIMER 私はHadoopを中心としたデータ基盤を取り扱うベンダー、Clouderaの社員です。 中立的に書くよう努めますが、所属組織によって発生するバイアスの完全な排除を保証することはできません。 以上をご了承の上、読み進めてください。 要約 データ基盤は、Hadoopの登場により非常に安価となり、今まででは不可能だった大量のデータを取り扱えるようになりました。 Hadoopは、NoSQLブームの中、処理エンジンであるMapReduceとストレージであるHDFSが
客といっても接客業でクレーム来るとかいう話じゃない。 職はIT系でプログラム書いてる。 会社だけで見るとホワイトな方(web系やベンチャー系とかと比べたら普通なのかも)。 数日前に twitter でホワイトバイトとか言って話題になってた、youtubeききながら作業したり、お菓子食べてもいいとかはもちろんだし、 上下関係も特にないし、出社が数分送れたくらいで何も言われないし、隣のビルのスーパーに飲み物買いに行ったっていい。 ここまでだとすごくホワイトに見える。 というか、会社単体で見れば残業と給与以外はホワイトなんだと思う。 ただ残業は忙しいときは毎日、日が変わるまで会社にいることもある。 逆に暇な時は社内ニート状態で好きにツール作ってみたりOSSいじったりもできるほどに極端。 で、一見楽そうに見えるが最近はやる気が全く起きないし仕事行くのにストレスがたまる。 これが本題なんだけど、客が
なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ
概要 サービスレベルをいかに設計し、いかに運用するか。自分なりの考えの整理です。 尋常ではない長さになりました。随時アップデートします。たぶん。 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) 作者: John Allspaw,Jesse Robbins,角征典出版社/メーカー: オライリージャパン発売日: 2011/05/14メディア: 大型本購入: 10人 クリック: 923回この商品を含むブログ (50件) を見る もくじ 概要 もくじ SLAとは何か 関係者が同じ目線を持つためのもの 火の一ヶ月間を経て…… SLAは契約ではなく、目標の合意に過ぎない SLA:設計のプラクティス サービスのレベルを設計する 機能観点でのレベル分け コア機能を定義する 非機能観点でのレベル分け オペレーションのレベルを設計する 対応速度のレベル分け 3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く