1. チームでトライ！ インフラ構築のススメ
I社@東陽町 大村 幸敬 （@yktko）
2010/05/20
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

10. インフラチーム運営のポイント
1. エンジニアだってスケールアウト
2. アジャイルインフラ構築
3. 「運用」をゴールに
9

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