チームでトライ！ インフラ構築のススメ

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

１．エンジニアだってスケールアウト

タスク↓↓↓↓↓↓↓

２人のとき

マスターパダワン

タスク↓↓↓↓

１人のとき

スーパーマン

11

１．エンジニアだってスケールアウト

タスク↓ ↓↓↓↓ ↓↓↓

３人のとき

リーダサブリーダ

スペシャリスト

タスク↓↓↓↓↓↓↓↓↓↓↓↓

ｎ人のとき

スペシャリスト アニキ

リーダサブリーダ

12

スケールアウト型チームの例

• Master-Slave方式のDB構成と似てる…なんとなく

– スペシャリスト間のjoinを減らす

– 上下間の情報同期

– ノードダウン→バックアップ稼動

• すべてのメンバに責任のある役割を持たせる

– それぞれの視点から気づきを促進

スペシャリスト：・個別技術の責任者・次はアニキ

アニキ：・スペシャリストの相談役・サブリーダのバックアップ

リーダ：・対外窓⼝（write受付）・要件・資⾦・要員管理・運⽤・技術レビュー/統括・障害時のサブ担当・新案件の獲得

サブリーダ：・現場の課題管理・技術レビュー/統括・障害時のメイン担当・リーダのバックアップ

heart-beat

13

２．アジャイルインフラ構築

• インフラ構築の現場は不確定要素が多い– ソフト/ハードのバージョンアップ

– 結局本番を使う

– 突発障害に伴う変更

• アジャイルが適合する！？– 変化を抱擁！

– 厳密なドキュメントは重い

– 「個人の能力」の最大化

14

具体的な施策

• スタンドアップミーティング– 毎朝10分 全員が集まり 実績/予定/問題を報告– 作業予定の確認、問題点の迅速な把握、エスカレーション

• スプリント計画と振り返り– 月曜に計画、金曜に振り返りと調整– 有識者の知識を共有– 広範囲な技術を学ぶのに有効

• ペア作業– 本番作業はダブルチェックが必要→ついでに教育の場に

• ベースラインの整備– 成果物ベースの荒いWBS（タスクよりステータス）– インシデントはすべて課題管理表へ→課題０＝リリース– 設計書の標準化→ヌケモレを防ぐ

15

３．「運用」をゴールに

• 宗教論争 や のめりこみ に対応する– 実装方式ではなくどのような運用になるか？に注目

– 対立構造ではなく共闘構造に持ち込む

• インフラエンジニア共通のゴール→「運用」– メンバのベクトルをあわせる

– 各々が動きやすいようにすべての情報を提供

– 厳密な管理より自発的な動きを

16

さて、今日は

• qpstudy

• 「インフラエンジニア初心者にやさしい勉強会」

• 「初心者」…？？？

• …初心者の方だけ聞いてください…

17

初心者からチームの一員へ

• チームで仕事するにはメンバを増やさないと– 初心者を一人前のチームメンバにするのもチームの仕事

• インフラエンジニアの特性– 好奇心旺盛 / 技術が好き / 唐揚げ好(ry

– オーケストラで言えばパーカッションのような

• 一人前って？– こいつに任せれば大丈夫

– 問題が出ても片付けられるよ

• 一人前になるためには？

18

１．実機でどんどん失敗しよう

• 機会を見つけてどんどん触る。壊す。– 本ではなく直接実機を触る

– 本番環境がベスト…あかんけど

• 経験＝失敗– 痛い目に遭わないと記憶に残らない

– 2回目の失敗はしない→成長

• システム的な限界がわかる– ここまでいくと戻れない

– ここまでなら戻れる

19

２．必ずログをとろう

• こんなことありませんか？– うまくいかなかったという事実はよく覚えている

– 試行錯誤してたらうまくいった！

– 喜んで次のターゲットに向かう

– そして何をやってうまくいったのかを覚えていない

– で、同じところで、またつまづく

• ログは自動的に取って保存＆ふりかえる– Teratermで時刻つきのログを自動的に取るとか

– 作業時刻だけ記録しておいて、あとから振り返る

– 全文検索との組み合わせがおススメ

20

３．まずは一度リリースしよう

• 例：性能情報の保存期間 1ヶ月はNG。5週間以上。– 私は最初気付きませんでした…

• 小さくてもいいから何か作って運用する– 設計時にあれこれ言われても重要性が理解できない

– 一度動かせば設計段階の問題がすぐに分かる

– 2回目以降は気付きが増えて質の高い設計になる

21

おわりに

• インフラエンジニアこそチームプレイ– その知られざる生態

– 広大な担当タスク・技術範囲

– インフラエンジニアの特性

• インフラチーム運営のポイント– エンジニアだってスケールアウト

– アジャイルインフラ構築

– 「運用」をゴールに

• 初心者からチームの一員へ– どんどん失敗

– かならずログ

– いちどはリリース

22

Enjoy Infrastructure Cooking!

• ご清聴ありがとうございました