65歳になる社員一人で保守
「伊藤忠商事、基幹系システム刷新へ 過去最大規模の開発費を投入」を読みました。SAP S/4HANAを使う大規模なERP（統合基幹業務システム）の導入プロジェクトとして注目に値するものだと思います。 ある部分が強く気になりました。以下に引用します。 「伊藤忠商事はSAP R/3を使った現行システムを稼働させた2001年、COBOLで作った30万行の規模のサブシステムも稼働させた。営業部門が入力した売り買いの情報を基幹システムが扱える伝票形式に変換する役割を担う」ものですが、「保守できる社員は異動などで減り、『現在は65歳の社員一人が担当している』」というのです。 同社は基幹系システムの再構築で問題を抜本的に解決するようですが、65歳になる一人の社員が保守を担当しているシステムというのは、経営面でもリスクになりかねない気がします。人ごとでないという方もいらっしゃるでしょう。システムの開発、運
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 米国でビデオオンデマンドサービスを提供しているNetflixは、Amazonクラウド上でわざとシステム障害を起こすためのツール、Chaos Monkeyをオープンソースで公開しました。 Chaos MonkeyはAmazonクラウド上で使うツール。Amazonクラウド上のインスタンスをランダムに落としまくることで、サービスに対して仮想的な障害を引き起こしてくれます。 NetflixはこのChaos Monkeyを実環境で使うことで、本物の障害が起きたとしてもサービスが継続できることをテストし続けてきました。Netflixのブログ「Chaos Monkey released into the wild」から引用します。 There are many fail
米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る
Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10％にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました。 リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。 AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。 同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。 Chaos Monkeyによっ
ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認
ヤフー子会社のファーストサーバは2012年7月31日、6月20日に発生した大規模障害（関連記事）についての調査報告書（最終報告書）を公表した（写真）。報告書は、ファーストサーバに利害関係のない3人の委員による「第三者調査委員会」（関連記事）が作成した。同社Webサイトに「要約版」を掲載している。 報告書は調査対象とする事故を、6月20日に発生した「第1事故」と、第1事故で消失したデータが想定外の場所に復元された「第2事故」（関連記事）の2つとしている。 1人だけ自作プログラムでメンテナンス 報告書は、第1事故の事実関係について次のように言及している。ファーストサーバではシステム変更を実行する際、社内マニュアルに沿って実行することになっており、第1事故の原因となったシステム変更の担当者（A氏）以外は社内マニュアルに従っていた。 ところが、A氏だけはマニュアルに従わず、自作の「更新プログラム」
サーバの構築作業や運用管理を自動化する「Chef」 (CADC研究レポート発表LT)
Yuuki NamikawaBackend/Infrastructure Engineer at CyberAgent, Inc.
Software Design 2011年9月号に運用エンジニアに関する記事を寄稿しました - blog.nomadscafe.jp
Software Design 2011年9月号にて『運用エンジニア「攻め」の仕事術」という特集の最初の章を担当させて頂きました。 運用エンジニアとはどんな職業で、何をすべきなのかを10年ぐらい前の昔話や前職の経験、今の職場で感じることなど自分の経歴を含めて書かせて頂きました。 今回の特集は、自分の他に@riywoさんや馬場さん(@netmarkjp)などの方々も記事を書いています。Mobageの半年で10億PV以上増えた話やアツい運用話、馬場さんの専業ならではの監視運用の話も非常に参考になりました。 中でも、馬場さんの記事中の、「障害対応のときに冷静でいる為のポイント」が参考になったので引用します 否が応でも心拍が早くなるので、心拍が早くなっていることを確認して自覚する 「冷静に」を心がける。心がけても冷静でいられないから、余計に心がける 呼吸、口調、タイプスピードを意図的にスピードダウ
第1回 DevOpsカンファレンスのお礼と話したことの補足
こんにちは。「ふいんき」と書いて「なぜか変換できない」の流れをやろうとしたらgoogle日本語入力だと余裕で変換できてしまい、沸き起こる複数の感情と戦っているhiroshiです。 去る2011/06/25(金)、DevOpsカンファレンスという勉強会でスピーカーをやらせてもらいました。そのお礼と、お話の補足をさせていただこうと思います。勉強会での発表は社を代表した内容にしたつもりですが、このエントリは、けっこう個人的な想いを多めにしてますので、もし異論反論ありましたら@hiroshi19790209までください＞＜。 去年末の「ZABBIX勉強会」以来のスピーカーで、あのときの参加者が60人くらい、今回も最初は80人くらいの募集だったから「実際くるのは応募人数の8掛けで60人くらいだろうから、このくらいの人数だったら経験済みだぜ！」と思って立候補したら、参加枠が120人まで伸びた上に当日も
10分でわかるDevOps
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ～エンタープライズのDevOpsを加速させる運用改善Tips～Yuki Ando
見えない「運用」 - 疲弊する運用現場 | Think IT（シンクイット）
インターネットのインフラ化と運用現場の疲弊 インターネットの急速な普及および発展により、インターネットを含むIT情報基盤は、社会基盤（インフラ）としての性格を色濃く帯びてきています。 しかし、これらのシステムやサービスを運用している現場では、メンバーに対する恒常的な高負荷、属人的な運用、トラブルの多発に悩まされるなど、事業継続面でのリスクを抱え、コストや効率面での課題に追われながらも、現場の個々人の過大な努力によって日々の運用を維持しているのが現状です。 なお、システムやサービスを「運用している現場」とは、例えば組織や企業において社内向け、対外向けなどを問わず「ユーザーや相手に対して何らかのサービスを提供している人たち」をイメージしています。 本連載では、従来であれば「現場ごとの個別事情に応じて、やり方が異なるため、標準化が難しい」と言われてきた「運用」について、「運用設計」という観点から
とある自社サービスの運用事例 - jsdo.it - Share JavaScript, HTML5 and CSS
// forked from sugyan's "wonderfl presentation template" http://jsdo.it/sugyan/presentation-base-wonderfl // まずはページ幅取得 var width = document.documentElement.clientWidth; document.body.className = 'slidemode'; // フォントサイズ調整 document.body.style.fontSize = width / 5 + '%'; var slides = []; var SV = 'slide view'; var SR = 'slide right'; var SL = 'slide left'; // スライドの各ページを取得 // divタグのクラス名で判定 var divs =
livedoor Techブログ : サーバのダイイングメッセージを汲み取る
どうも、はじめまして。DATAHOTELサービスでフルマネージドホスティングのオペレータをやらせて頂いておりますDO(ドゥー)といいます。 テックブログなるものではございますが、私が技術を語るなどとは... オペレータとして培ったこれまでの経験から、「まぁ難なく」という範囲内でひとつこの場をお借りして少しだけ語らせて頂ければ、と思っております。 マネージメント 「まぁ難なく」と言ったところで、まず私の業務内容の範囲がどれだけあるのかお話ししないといけませんよね。業務内容をひと言で言いますと、サーバのマネージメント。単にマネージメントと言いましても、その分野は多岐に亘りサーバのセットアップから始まり、プラットフォームやアプリケーションの構築やパラメータの調整、顧客の運用を手助けするための提案、また安定運用をご提供する為の監視、障害発生時の復旧作業など、様々な分野のマネージメントを行っているの
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
富士通、データセンター運用の負荷を軽減するアプリケーション変更管理化ソフト
富士通株式会社は10月20日、ITILに準拠した変更管理ソフトウェア「Systemwalker IT Change Manager」を発表した。アプリケーションの実行環境を認識した上で、変更を自動的に行える製品。同日より販売を開始する。 Systemwalker IT Change Managerは、アプリケーションの変更作業を自動化するためのソフトウェア。エージェントソフトウェアが収集したアプリケーションの実行環境と構成情報を、管理サーバーのCMDB（構成管理データベース）へ自動的に格納する機能を搭載。その情報をもとに適用すべきサーバーを抽出し、アプリケーションの変更を、実行環境にあわせた方法で自動的に配布・適用できる。 実行環境は富士通の「Interstage」とマイクロソフトの.NETをまずサポートし、2010年度の早いうちに日本オラクルの「Oracle WebLogic」と日本IB
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 （この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題」の続きです） キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に（友人たちの）情報を集めることがで
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHP、C++、Memcache、MySQLなどのソフトウェア群によって支えられています（同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照）。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLの冗長化 2013-01-24
ソーシャルゲームスケールアウトの歴史
AWS クックパッドの運用事例
第一回 DevOpsカンファレンス
新卒インフラエンジニア２年目