DevOpsカンファレンスいってきた

6月24日、先週の金曜の話ですがDevOpsカンファレンスに行きました。
こんな素晴らしい会合に生で参加出来てとても幸せだったので色々書いてみます。

わたしとDevOpsとの出会い

1年前くらいだと思いますが、自社のシステム障害が多発してしんどい状況が続いていて、特にミドルウェアから
下のレイヤになるとほぼオレの出番だった頃、id:MIZZY(@gosukenator)さんのスライドとともにDevOpsと言う言葉に出会い、
なんかすげー感動した覚えがあります。
感動のあまりインフラMTGと言う名前の会議をOpsMTGに改名してしまったくらいです。
今考えるとDevOpsをわざわざ分けちゃダメじゃんとか今更気付いたりしてますが。

当日

今回Devな人の反応も見たいと思い同僚をお誘いしてみました。(ほんと一緒に来てくれてありがとう!)
発表後の懇親会でいろいろしゃべってたんですが、モニタリングだとかサーバ構成なんかは元々興味があった様子でした。
あと実はこっそりサーバ構成図などを見てましたなんて話をされ、その時は
「おー、構成図見るなんて感心だねー」とか適当に話してましたが、こっそりとしてしまう
所を見るとやっぱり自社にも見えない壁というかサイロがあるんだなぁと言う事を実感しました。
この辺がオープンになって、DevOpsカルチャーが浸透して、ツールもうまく使いこなして行くと
改善とかがうまく回るようになるんじゃないかなーと思いました。



サイロといえばENTRANCE
http://www.konami.jp/mgo/jp/images/special/eyes04_01.jpg


あとOpsは広い意味ではヘルプデスクだとか運用系全般が入るそうですが、自社の場合
運用系に携わっている人たちは結構沢山いますから、汎用的な所はシェアして行けると
幸せになれそうですね。カルチャーはもとより、ツール使うとか、プロセスとか。
泥臭い運用、であきらめない。

メモ

  • 方向性の違い dev新しい機能を追加する ops安定させる
  • exclusive(排他的)では無く、inclusive(排他的の逆の意味で)踏み越えてかかわっていくというムーブメント、流行
  • 協調して働くカルチャーと、ツールとプロセスと
  • 選定基準はコミュニティで開発されているもの。個人で開発している物は避ける
  • パフォーマンス改善
    • 指標となる数値を出す(PVとレスポンスタイム)
    • 優先順位をつける
    • 優先順位の付け方 PVとレスポンスタイムを使う
  • 監視のローテーション 平日夜間は全員、週末は月1位のローテーション
  • 2日は放置できるように冗長性を常に確保
  • 開発エンジニアにも担当サービスのアラート
  • サービス障害が起きたら当番以外も出動
  • ジェンキンス氏 http://jenkins-ci.org/
  • プログラマが監視の1時受け、監視設定をやっている
  • 昔はアウトソーシング監視だった
  • アウトソースの弊害
    • なんとなく再起動が発動してなんとなく復旧している
    • 何が起きているか見えづらい 監視項目の洗い出しがしにくい
    • インフラが障害対応することが極端に多い
    • 監視項目がつたわらない
  • 監視のソリューションは各サービス運用者(Devな人?)が決定する
  • devs?ops?5人なんでそんなのないっす
  • SVN->gitになった
    • 3人くらいならどのソースいじるか話せばよかった
    • SVNのマージがきつい。また聞いたSVNのマージきつい話
    • git賢い
  • デプロイ
  • サーバ構成図
    • 付箋を使う!
    • 400台超えたあたりから限界。400台まではいけるのか
  • 監視 基本全員。夜間、休日は当番制
    • PC肌身離すな
    • 最悪電話をあきらめるな
    • 電話諦めない
  • 使ってるツールは自社でも使っている物がそこそこあった
  • モバゲさんの話はこっそり不具合対応してたのであんまり聞けず、、、

個人的な胸熱ポイント

@hiroshi19790209さんのデコログ宣伝タイムを見ていて自社のサービスをここまで語れるエンジニアっていいなと思った。
情熱プログラマを思い出しました。


内容はid:marqsさんのがまとまっていますのでおすすめです
http://d.hatena.ne.jp/marqs/20110625/1308973680