タグ

operationに関するyassのブックマーク (9)

  • 守る - cybozu.com 運用の裏側

    サイボウズ社のクラウドサービス「kintone」の私的勉強会@札幌(第1回)で使用した資料です。 勉強会の詳細なレポートはこちら http://radical-bridge.com/information/kintone_cafe_at_vol1kintone.html

    守る - cybozu.com 運用の裏側
  • 続・MCollectiveのインストールと動作確認 - hack in 3 minutes

    ずっと前に一度書いたMCollective、#devopsdaysで出てて、チラホラとブクマがついたりしてたのですが、いかんせん情報が古いし、インストールしてただけだしなので再度まとめてみます。 あとOrchestration的なものでいうと、自分の周りの今の状況は Aサービスは管理サーバ全台でのコマンド実行兼デプロイツールを自作している Bサービスはpssh使ってちょっと楽になった Cサービスは未だにsshでログインして頑張ってる みたいに結構バラバラで、じゃあCapistranoとかに一個決めてゴリゴリ頑張るかーというと何かちょっとそういう時代は一旦過ぎてダルくて、もう少しオペレーションフレンドリでいい感じのが無いかを模索していたところ、ちょっと見えてきた感があるのでそれも兼ねて。 特徴とかは以前のエントリに書いたから割愛。 テスト用の構成は mcollective-client, a

  • NoOps - その意味と関連する議論

    原文(投稿日:2012/03/16)へのリンク 1年前に Forrester は Augment DevOps with NoOps (DevOps を補強する NoOps) というレポートを公開した。その中で同社は,近い将来に一部企業のクラウド依存がますます高まり,開発者のビルドやテスト,デプロイなどの作業がさらに自動化されることによって NoOps に到達する,と予想している。NoOps という用語からは,それらの企業が運用スタッフの雇用を止めるような印象を受ける。しかし実際のレポートは,開発者が運用を実施する上でのより優れた自動化ツールへの取り組みや,手動操作の必要性を低減するツールに関して言及したものだ。 クラウドコンピューティングの新たな発展は,オンデマンドなインフラストラクチャやリソースのセルフプロビジョニング,柔軟なアプリケーションアーキテクチャという新しい時代の到来を告げる

    NoOps - その意味と関連する議論
  • 構築運用屋から見たHDD+αな話。 - おっホイ別館 − はてな村の物語

    こちらのTogetterエントリ サーバのディスクの話 http://togetter.com/li/238411 に、大量にはてブがついているのをみて、今までの私の話などを。 このエントリが、何故に多くの人の関心を寄せるか…というと、「RAIDの一般化」という部分が大きいと思います。 今じゃSATA(&SAS)RAIDが、Intelチップに機能として搭載され、数万円台の外部NAS、RAIDカードで、RAID5,6どころか1+0や50まで構築できる時代。 「Diskが壊れても、データは壊れない!」という売り文句は、非常に魅力的だったりします。 今ではSATAのRAID1(HDD2でミラーするだけ)なら、数千円のレベルでカードが買えますね。 では、Intelのチップセットや激安RAIDカードで、保護的RAIDを組んだ状況で、どれだけデータ保護が出来るかというと、 HDDの故障を救える確率と

    構築運用屋から見たHDD+αな話。 - おっホイ別館 − はてな村の物語
  • アプリエンジニア向け:「サーバがなんか重い」時にすること - Qiita

    アプリケーションエンジニアの人には「なんか重い」という状況に遭遇したらインフラの人にタスクを投げる、という人もいるかも知れません。けど、その重さのどこに原因があるのか。CPUか、ネットワークか、IOかくらいの診断はできた方がアプリ開発においても有益です。 「せっかくつくったシステムがなんか重い」 そんな時にアプリケーションエンジニアとしてできることを書きます。 職のインフラの人にはぬるい内容だと思います。何を隠そう僕自身がアプリ寄りの人間なので、突っ込んだ話はできないのです。あしからずご了承ください。 なんかサーバが重いなー まずはロードアベレージを調べる サーバが重いと思ったら、まず真っ先にすべきことは対象ホストにSSH接続してロードアベレージを調べることでしょう。ロードアベレージとは 実行されずに待たされているプロセスの数 のことで、多すぎるとやばいと認識しておきましょう。ロードアベ

    アプリエンジニア向け:「サーバがなんか重い」時にすること - Qiita
  • MongoDB vs Mysql. A devops point of view

    A fotopedia presentation made at the MongoDay 2012 in Paris at Xebia Office. Talk by Pierre Baillet and Mathieu Poumeyrol. French Article about the presentation: http://www.touilleur-express.fr/2012/02/06/mongodb-retour-sur-experience-chez-fotopedia/ Video to come.Read less

    MongoDB vs Mysql. A devops point of view
  • A Systems Policy

  • SAP:ソーシャルアプリ開発、インフラ構築時に使える10個のチェックリスト | tracpath.com

    ソーシャルアプリ開発者、とくにインフラを担当している技術者の方はシステム構成をどのようにしていますか。 最近の一般的だと思われるシステム構成とソーシャルアプリ開発のインフラ構築時に使える10個のチェックリストをご紹介します。 実際にソーシャルアプリやソーシャルゲームのシステム構成として稼働実績があるシステム構成になりますので参考になるかもしれません。 インフラ構築に使える10個のチェックリスト 必要なときにスケールアウト、スケールアップができるか トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか メンテナンス時間を最小化できるか ログファイルをいつでも参照、見える化(

    SAP:ソーシャルアプリ開発、インフラ構築時に使える10個のチェックリスト | tracpath.com
  • 障害対応の工数は謎だらけ - rabbit2goのブログ

    開発現場では、新規の開発案件等に対して必要工数の見積もりを要求され、それはそれなりに難しいものが有るけれど、それ以上に難しいのは障害対応の工数見積もりだと思う。もちろん、内容を一目見て容易に原因と修正内容が分かるものがある一方で、原因の調査に難航し、さらに修正確認にも手間取るものが珍しくなかったりする。 何故そんなに時間がかかってしまうのだろうかと思って改めて考えてみたところ、対応に時間を要するものはこんな特徴を持っているようだ。 障害レポートに記載されている再現手順に従っても問題が再現しない。記載されていない情報に相違があるらしいので、レポートの報告者に詳細を問い合わせをする必要があり、そのやり取りに時間がかかってしまう。 原因調査のためにログ出力を追加したら問題が発生しなくなってしまう。ログ出力処理が、タイミングを何か変えてしまっているらしいが、その原因や影響理由が分からない。 不特定

    障害対応の工数は謎だらけ - rabbit2goのブログ
  • 1