SlideShare a Scribd company logo

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

•
•
Yukitaka Ohmura
Yukitaka Ohmura

Related slideshows

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

More Related Content

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

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