運用インフラエンジニア指針

1. ウェブオペレーション
ＰＳ事業部 運用部

2. DC 移設
• 無事完了しました！！！！
• おめでとうございます！！
• 皆さんが有難うございます！！！

3. 会者定離
• 会者 ( えしゃ ) 定離 ( じょうり )
• 出典は遺教経（ゆいきょうぎょう）
• 会うは別れの始め
• 運用の仕事について、共有いたします

4. 単語
• オペレーション
• オペレーター
• インフラエンジニア
– サーバエンジニア
– ネットワークエンジニア
• 運用エンジニア

5. 運用、オペレーション
• 運用やオペレーションというと、定型の
作業が多く技術的成長が期待できない業
務だと思われ、開発と運用という対比で
は運用側が一段低く見られがちかもしれ
ない
• オペレーション業界、組織の技術標準が
恥ずかしいほど低いということを正直に
認めなければならない

6. オペレーションとは
• 実はシステムを成長させる
という技術的チャレンジの
多いエキサイティングな仕
事です

7. オペレーターへ
• 運用エンジニアとしての自分の業務は、
アプリケーションエンジニアが作成した
アプリケーションとインフラエンジニア
が設置したサーバとを結び付け、ソフト
ウェアの側から可用性（ availability ）とス
ケーラビリティ（ scalability ）を確保し、
アプリケーションのパフォーマンスを向
上させること

8. 可用性とは？
• 可用性の数値としての表現は稼働率
• 可用性 100 ％のサイトがない
– マーフィーの法則をご参照ください
• 可用性 99.9999% はミソロジー
• 可用性 99.999% は技術と運が半々
• 99.95% 以上の場合は、一つ「 9 」が 10 倍のコスト
をかかる
– Amazon の SLA は 99.95%
– 2007 年 ebay の可用性は 99.94%
– 2008 年 1 月から 4 月の間、 twitter の可用性は
98.72%

9. パフォーマンスを向上とは
• インテル：「ソフトウェアもムーアの法
則に従う必要がある」
• モーアの法則とは別に、アムダールの法
則というものがある
– あるコンピュータが処理の一部を 100 倍やそ
れ以上に高速化できたとしても、それによっ
て影響を受ける部分が与えられたタスクの実
行時間の 12% でしかないとしたら、全体とし
ては最大でも 1/(1-0.12)=1.136 倍の性能にしか
ならない。

10. スケーラビリティ
• 「老子道徳経」の「道生一、一生二、二生三、
三生万物（道は一を生み、一は二を生み、二は
三を生み、三は万物を生む）」
– 道は運用目標
– 一は方向
– 二は戦略
– 三はアーキテクチャー

11. オペレーション専門のエンジニ
ア
• 可用性とスケーラビリティの確保
– サーバセットアップの過程の効率化・自動化
• サーバか端末まで全体のパフォーマンスを向上させる
– 絵文字サーバ
• 運用に直接関わらない活動で部内の連携を
– CSS ファイルのサイズなど
• 情報発信とエンジニアとしての成長
– 最新技術情報共有、勉強会
• 技術の幅を広げるのために
– 監視整備
– ボトルネック解消
• ＥＴＣ…

12. オペレーション何をする？
アジャイルインフラス
トラクチャ
※ アジャイルが使いた
くない

13. おしゃべりでご飯は炊けない
• 本物のアジャイルチームはみずからアジャイ
ルであるとは言わない。アジャイルを声高に
言うチームに限って、アジャイルではないこ
とが多い。
• 実感していない者の言葉は軽い -- 安藤百福氏
※ カーゴ・カルト（ wikipedia ）
• 言葉にできるタオは、本当のタオではない

14. しなければい
けないこと

15. アジャイルインフラストラクチ
ャ
• インフラはアプリケーションである
• バージョン管理
• 構成管理と自動デプロイ
• 監視
• 開発のライフサイクル、継続的統合、障
害復旧
• 情報ラジエーター

16. インフラはアプリケーションで
ある
• 将来は、コンピュータ処理・ストレージ
・ネットワークリソースをコードで操作
することになる
• インフラ管理はソフトウェアを書くこと
だ

17. バージョン管理
• バージョン管理：正気の土台
• バージョン管理は、一貫性・柔軟性・変
更管理・ロールバック・障害回復など、
必要条件である

18. 構成管理と自動デプロイ
• 自動化
• 自動化
• 自動化
• デプロイはボタン一発でなければならな
い
– Flickr は一日 17 回デプロイ
– Facebook は平均 8 分サーバがアップデート
する

19. 監視
• 監視システムをソフトウェア開発のテス
トと比較している
• サービスの稼働を監視で確認できなけれ
ば、サービスがデプロイされたとは言え
ない
• 製品を売れば、販売動向を監視しなけれ
ばならない

20. 開発のライフサイクル、継続的
統合、障害復旧
• 開発のライフサイクルは、本番と同じ環
境にしなければならない
• 継続的統合は、新しいマシンの設置・設
定・新しいビルドのデプロイ・テストと
監視の実行・結果の保存という流れにな
る

21. 情報ラジエーター
• 監視の目的は、デプロイ・使用パターン
・ネットワーク・ハードウェアに関連し
た問題をできるだけ早く発見することだ
• 理想的な解決策は、全体像をしめすダッ
シュボードとドリルダウン機能によりメ
トリクスの詳細表示だ

22. やるべきこと

23. アジャイルインフラストラクチ
ャ
• 内省的プロセス改善
• 漸進的な変化とリファクタリング
• 可能な限りシンプルに
• 関心の分離
• 技術的負債
• 継続的デプロイ
• ペア
• 流れを管理する

24. 内省的プロセス改善
• 一歩ずつ着実に、アプリケーションであるイン
フラを改善する

25. 漸進的な変化とリファクタリン
グ
• 試してみればよい

26. 可能な限りシンプルに
• KISS （ Keep It Simple, Stupid ）
※ アジャイル小話
Q ：電球を替えるのにアジャイル開発者は
何人必要だ
Ａ：家に火をつけてしまうだろう

27. 関心の分離
• シンプルな疎結合のサービスを管理する
方が、設定の衝突や干渉を心配する必要
がない

28. 技術的負債
• 今すぐにできる表面的なソリューション
ばかり選んでいると、最終的には技術的
負債を返済できなくなってしまう

29. 継続的デプロイ
• デプロイとは、開発から運用にコードを
渡す儀式である
• 固定費とデプロイの儀式がゼロになるま
で自動化すること

30. • ペア
• 流れを管理する
– カンバン

31. まとめ
• 運用は今後も消えることはない、ますます重要で、
強力なものになる
• システム管理は、スキルの高い頭のいい人たちが集
まる奥深い分野だ
• 一つの考え方や視点に囚われてはいけない。最善の
アイデアは、文化が衝突したときに出てくるものだ
• 優れたものを見つけたら、活用しましょう
• 「アジャイル」になるかどうかなんて気になる。「
すごい」人を目指す
• 技術的な問題を解決するのは人だ