Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20100520 【qpstudy01】 チームでトライ!インフラ構築のススメ

20,391 views

Published on

Published in: Technology

20100520 【qpstudy01】 チームでトライ!インフラ構築のススメ

  1. 1. チームでトライ! インフラ構築のススメ I社@東陽町 大村 幸敬 (@yktko) 2010/05/20 qpstudy01
  2. 2. 自分 芝生 • 大村幸敬(@yktko) 関西 インフラ 娘^2 エンジニア • SIer • インフラ専門 • 主に金融機関 オープン ソース • アプリ以外全部 • 構築→納品 • 保守少し • 数名×数チーム 酒 あたらしもの • 提案から実装まで 1
  3. 3. 伝えたいこと • インフラエンジニアこそチームプレイ – その知られざる生態 – 広大な担当タスク・技術範囲 – インフラエンジニアの特性 • インフラチーム運営のポイント – エンジニアだってスケールアウト – アジャイルインフラ構築 – 「運用」をゴールに • 初心者からチームの一員へ – どんどん失敗 – かならずログ – いちどはリリース 2
  4. 4. インフラエンジニアの生態 • アラートメールで起こされ • 朝からDCに直行し • ファンの轟音と強烈な冷房にも負けず • サービスが止まれば顧客の矢面に立たされ • 社内では手元の仮想環境でこっそり新技術を検証 • 帰りがけに営業から見積りを依頼され • 一人残って構成図を書く • 昼にはカレー • 夜には唐揚げ 3
  5. 5. なんで? • こんなに大変なのか? • 振り返ってみる – インフラエンジニアの担当タスク – インフラエンジニアの担当技術 4
  6. 6. インフラ構築タスクの全体像 要件定義 要件定義 基本設計(アーキ) 基本設計(アーキ) 詳細設計 詳細設計 構築/UT 構築/UT ITa/ITb ITa/ITb ST ST 試⾏ 試⾏ 本番 本番 ⾮機能 ⾮機能 設計 設計 NW NW NW NW NW NW 性能 性能 要件 要件 ⽅針 ⽅針 HW HW HW HW OS OS OS OS AP AP アプリケーションサーバ アプリケーションサーバ DB DB データベース データベース (その他) (その他) (その他) (その他) (その他) (その他) 基本設計(運⽤) 基本設計(運⽤) 運⽤ 監視 監視 監視ツール 監視 サイクル 運⽤ 監視ツール 監視 サイクル ⽅針 ⽅針 backup backup バックアップツール backup バックアップツール backup ck 運⽤ 運⽤ 運⽤シェル 運⽤シェル 運⽤ 運⽤ 運⽤/障害 運⽤/障害 ta ジョブネット ジョブネット ジョブネット ジョブネット マニュアル マニュアル マニュアル ll S サポート u マニュアル サポート 移⾏ 移⾏ 計画 計画 移設・移⾏ 移設・移⾏ 初期 初期 IT IT F ST ST 試⾏ 試⾏ 本番 本番 5
  7. 7. インフラエンジニアの技術領域 カテゴリ 個別技術名 業務アプリケーションを動かす技術 フレームワーク/Web/DB 性能・信頼性のための技術 クラスタ/負荷分散/memcached 運用シェルの実装言語 Perl/Ruby/bash/powershell/bat 運用のための技術 バックアップ/監視/ジョブネット OSに関する技術 Linux/Windows/PaaS ネットワーク技術 スイッチ/ルータ/WAN プロジェクト実行の技術 テスト計画/移行計画/運用計画 範 囲 ビジネスマン/障害対応担当者として 論理思考/仮説思考/説明能力 広 6
  8. 8. 一人よりチーム • 一人ではどうにもならない – 突発的な障害対応 – 体調が悪い – サーバ台数が増える • バランシング&スケールアウト – インフラエンジニアの特性にあった 7
  9. 9. インフラエンジニアの特性 • 特定技術に特化する – 興味のあるところを徹底的に/それ以外はあまり… – 全体を分かっている人は少ない • 個人プレイが必要 – 全体がわからないと確信を持って仕事できない – 忙しいので後輩には「man見ろ」 / 自分でやったほうが早い • 宗教^h^hこだわり – 技術的な設計・実装方針でぶつかる • vi/emacs、Linux/Windows • percussionに似てる 8
  10. 10. インフラチーム運営のポイント 1. エンジニアだってスケールアウト 2. アジャイルインフラ構築 3. 「運用」をゴールに 9
  11. 11. 1.エンジニアだってスケールアウト 1人のとき 2人のとき タスク タスク ↓↓↓↓ ↓↓↓↓ ↓↓↓ パダワン マスター スーパーマン 10
  12. 12. 1.エンジニアだってスケールアウト 3人のとき n人のとき タスク タスク ↓ ↓↓↓ ↓↓↓↓↓↓ ↓ ↓↓↓ ↓↓↓↓↓↓ サブリーダ リーダ サブリーダ リーダ スペシャリスト スペシャリスト アニキ 11
  13. 13. スケールアウト型チームの例 サブリーダ: リーダ: ・現場の課題管理 ・対外窓⼝(write受付) ・技術レビュー/統括 heart-beat ・要件・資⾦・要員管理 ・障害時のメイン担当 ・運⽤・技術レビュー/統括 ・リーダのバックアップ ・障害時のサブ担当 ・新案件の獲得 スペシャリスト: アニキ: ・個別技術の責任者 ・スペシャリストの相談役 ・次はアニキ ・サブリーダのバックアップ • Master-Slave方式のDB構成と似てる…なんとなく – スペシャリスト間のjoinを減らす – 上下間の情報同期 – ノードダウン→バックアップ稼動 • すべてのメンバに責任のある役割を持たせる – それぞれの視点から気づきを促進 12
  14. 14. 2.アジャイルインフラ構築 • インフラ構築の現場は不確定要素が多い – ソフト/ハードのバージョンアップ – 結局本番を使う – 突発障害に伴う変更 • アジャイルが適合する!? – 変化を抱擁! – 厳密なドキュメントは重い – 「個人の能力」の最大化 13
  15. 15. 具体的な施策 • スタンドアップミーティング – 毎朝10分 全員が集まり 実績/予定/問題を報告 – 作業予定の確認、問題点の迅速な把握、エスカレーション • スプリント計画と振り返り – 月曜に計画、金曜に振り返りと調整 – 有識者の知識を共有 – 広範囲な技術を学ぶのに有効 • ペア作業 – 本番作業はダブルチェックが必要→ついでに教育の場に • ベースラインの整備 – 成果物ベースの荒いWBS(タスクよりステータス) – インシデントはすべて課題管理表へ→課題0=リリース – 設計書の標準化→ヌケモレを防ぐ 14
  16. 16. 3.「運用」をゴールに • 宗教論争 や のめりこみ に対応する – 実装方式ではなくどのような運用になるか?に注目 – 対立構造ではなく共闘構造に持ち込む • インフラエンジニア共通のゴール→「運用」 – メンバのベクトルをあわせる – 各々が動きやすいようにすべての情報を提供 – 厳密な管理より自発的な動きを 15
  17. 17. さて、今日は • qpstudy • 「インフラエンジニア初心者にやさしい勉強会」 • 「初心者」…??? • …初心者の方だけ聞いてください… 16
  18. 18. 初心者からチームの一員へ • チームで仕事するにはメンバを増やさないと – 初心者を一人前のチームメンバにするのもチームの仕事 • インフラエンジニアの特性 – 好奇心旺盛 / 技術が好き / 唐揚げ好(ry – オーケストラで言えばパーカッションのような • 一人前って? – こいつに任せれば大丈夫 – 問題が出ても片付けられるよ • 一人前になるためには? 17
  19. 19. 1.実機でどんどん失敗しよう • 機会を見つけてどんどん触る。壊す。 – 本ではなく直接実機を触る – 本番環境がベスト…あかんけど • 経験=失敗 – 痛い目に遭わないと記憶に残らない – 2回目の失敗はしない→成長 • システム的な限界がわかる – ここまでいくと戻れない – ここまでなら戻れる 18
  20. 20. 2.必ずログをとろう • こんなことありませんか? – うまくいかなかったという事実はよく覚えている – 試行錯誤してたらうまくいった! – 喜んで次のターゲットに向かう – そして何をやってうまくいったのかを覚えていない – で、同じところで、またつまづく • ログは自動的に取って保存&ふりかえる – Teratermで時刻つきのログを自動的に取るとか – 作業時刻だけ記録しておいて、あとから振り返る – 全文検索との組み合わせがおススメ 19
  21. 21. 3.まずは一度リリースしよう • 例:性能情報の保存期間 1ヶ月はNG。5週間以上。 – 私は最初気付きませんでした… • 小さくてもいいから何か作って運用する – 設計時にあれこれ言われても重要性が理解できない – 一度動かせば設計段階の問題がすぐに分かる – 2回目以降は気付きが増えて質の高い設計になる 20
  22. 22. おわりに • インフラエンジニアこそチームプレイ – その知られざる生態 – 広大な担当タスク・技術範囲 – インフラエンジニアの特性 • インフラチーム運営のポイント – エンジニアだってスケールアウト – アジャイルインフラ構築 – 「運用」をゴールに • 初心者からチームの一員へ – どんどん失敗 – かならずログ – いちどはリリース 21
  23. 23. Enjoy Infrastructure Cooking! • ご清聴ありがとうございました 22

×