タグ

運用に関するairj12のブックマーク (11)

  • 大規模障害から1年余り、あの企業が「その後」を語った

    「この度は取材をお受けしましたが、どう対応したらよいか。今でも迷いがあります」。担当者は取材の冒頭で、心境をこう吐露した。 記者は取材のためレンタルサーバー事業を手掛けるファーストサーバ(社:大阪市)を訪れた。1年半ほど前に、顧客企業が利用していたサーバー約5700台のデータをほぼ消失させる大規模障害を起こした事業者だ。 今回の取材は、過去に失敗を経験した複数の企業や公的団体に申し込んだ。目的は、「IT運用の失敗から技術者がどう学び、再発防止に取り組むべきか」をまとめる企画記事を執筆するためだ。 中でもファーストサーバは、運用のプロであるべきITベンダーが、一部とはいえ現場担当者のずさんな運用作業を見逃していた実態が明るみになり、個人としても大きな衝撃を受けた。失敗を経てどう体制を立て直したのか、大いに興味があった。 「非技術者」にも分かる再発防止策を:ファーストサーバ 簡単に、ファース

    大規模障害から1年余り、あの企業が「その後」を語った
  • 完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか? まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。

    完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ
  • ScaleOut | Supership

    2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 件に関する詳細は、プレスリリースをご確認ください。

    ScaleOut | Supership
  • #java_ja で例外とロギングについて勉強会をやるというのでいってきた&飛び込みLTやった&運用の視点から見たアプリケーションのログについて - たごもりすメモ

    LOG.debug("nice catch!") - connpass 2012/06/27 java-ja 『LOG.debug("nice catch!")』#java_ja #javaja - Togetterまとめ blogエントリを書くまでがjava-jaだと聞いたのでとりあえず書く。超まとまってません。各スピーカーの話の内容については他の人のblogに(たぶん)書いてあるのでそっちを見るとかTogetterを眺めるとかすればよいのではないでしょうか。 主催のみなさま、および会場提供のGREEさま、ありがとうございました。そういえばGREEでの勉強会って初めて参加した気がする。六木ヒルズの入館、だいぶ簡単になりましたね。 いってきた どっちかというとアプリケーションのコード書く人が多かったんですかね。という感じで、アプリケーションコードからいかにして例外を投げるか、それをどのよ

    airj12
    airj12 2012/06/29
    「WARN/ERRORで監視、調査時にはINFOも必要だから出しとけ」派 / WARN・ERRORしかログ出さないのは不具合が無い(予想外の動きをしない)前提な気が
  • 大きなリリースの際にチェックすべき34のこと

    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) 以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか

    大きなリリースの際にチェックすべき34のこと
  • 米Yahoo!がシステムダウンしない5つの理由

    昨年の10月14日、米Yahoo!のトップページがダウンしたと、米Huffington Postが記事「Yahoo DOWN: Yahoo.com Outage Reported」で伝えました。米Yahoo!にとってトップページがダウンすることはきわめてまれなことで、この件が発生するまでほぼ10年にわたりトップページのダウンは起きていなかったと言われています。 その米Yahoo!はシステムダウンを防ぐためにどのような取り組みをしているのか? 米オライリーが主催したイベント「Velocity 2011」で、Yahoo!サービスエンジニアリング部門のVice President、Jake Loomisが行ったセッション「Why the Yahoo FrontPage Went Down and Why It Didn't Go Down For up to a Decade before Th

    米Yahoo!がシステムダウンしない5つの理由
    airj12
    airj12 2011/06/28
    合理的だなー
  • クラウド時代にこそCOBOLなベテランから学ぶこと - 急がば回れ、選ぶなら近道

    言うまでもなく、COBOLなベテランは非同期バッチ処理の達人が多い。 日ではこの手のベテランが多い。 まず世界でも例がないほどだと思う。 クラウド時代はむしろ非同期処理のオンパレードであり、 学ぶべき点はたくさんある。 こと運用レベルや、対障害設計は神レベルの人が多いので まじでノウハウは受け継ぐべし。 個人的に達人系の技のポイントをまとめておく 1.コンテキストを外部から与える 一種のDI的な考え方である。 但し、あくまで運用目線であることが重要。 通常のDIは開発効率を目的に考えていることが多く見受けられるが 非同期処理についてのDI的な考えは運用効率性の重視だ。 対障害設計をする上で、もっとも大事なことは 「コンテキストがまっさきに見えることだ。」 これはDI的は発想とはまるで違う。 今走っている処理は、 ・どういうモノで、 ・何を想定していて、 ・どういうスケジュールになっていて

    クラウド時代にこそCOBOLなベテランから学ぶこと - 急がば回れ、選ぶなら近道
    airj12
    airj12 2011/06/13
    正しく「運用でカバー」を考えられる人は超貴重
  • DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール

    4月11日から米サンタクララで行われた「MySQL Conference & Expo 2011」。このイベントでDeNAの松信嘉範(まつのぶよしのり)氏が、同社の大規模なMySQLの運用を支えている技術とツールについてのセッション「Automated, Non-Stop MySQL Operations and Failover」を行いました。 プレゼンテーションの中で、社内で利用しているフェイルオーバーの自動化ツールをオープンソース化することにも触れています(英語のドキュメントも作成中とのこと)。 MySQLの大規模運用における自動フェイルオーバーは、特にクラウドでのMySQLの利用が増えるにつれてニーズが高まる分野と思われます。セッションのスライドが公開されていますので、そのポイントを紹介していきます。 自動化されたノンストップなMySQLの運用 ソーシャルゲームでは高可用性が強く求

    DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール
    airj12
    airj12 2011/04/15
    めもめも
  • 3年使ったRedmineの使い方について共有したい10のこと

    前回は、1000人のエンジニアRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考

    3年使ったRedmineの使い方について共有したい10のこと
    airj12
    airj12 2011/04/06
    数年前に一度使ったきりだなぁ、好きなのに。
  • 多人数開発で Git を使う場合の環境構築 | GREE Engineering

    こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙

    多人数開発で Git を使う場合の環境構築 | GREE Engineering
    airj12
    airj12 2011/03/22
    めも。
  • 災害にあったITシステムを操作しなければならない人が知るべきこと

    東北地方太平洋沖地震が金曜日に発生し、被災された皆様には心よりお見舞い申し上げます。 そんな中でも、この月曜日から多くのIT関係者が被災したかもしれないITシステムの復旧に取りかかるのではないかと思います。そうした方々に役に立つ記事を届けられないだろうかと、ユニアデックスの高橋優亮氏に相談したところ、大いなるご賛同をいただき有志の方々とノウハウをまとめたこの文書「災害にあったITシステムを操作しなければならない人が知るべきこと v0.2」を作り上げていただきました。 文書の主眼は被災したITシステムを復旧させようとする方々に向けた情報提供ですが、システムに電源を入れる前の注意事項、電源投入順序の考え方などの説明は、これから関東地方で計画されている停電が起きたあとのシステム再起動の際などにも参考になると思います。 文書はどなたにでも活用していただけるようにGNU Free Documen

    災害にあったITシステムを操作しなければならない人が知るべきこと
  • 1