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