Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

qpstudy 2014.04 インフラエンジニアとは、なんだ

12,817 views

Published on

インフラエンジニアというものを、次の側面で理解する
- レイヤー
- スキル
- フェーズ

Published in: Technology
  • Be the first to comment

qpstudy 2014.04 インフラエンジニアとは、なんだ

  1. 1. インフラ エンジニア とは、なんだ 今だから伝えられる、基礎中の基礎
  2. 2. おまえは、なんだ しょっさん(0x27) 中級 ITアーキテクト 初級 ITコンサルタント 中級 アクアリスト 上級 Perfume Enthusiast 超級 深田恭子は俺の嫁 封印 ナイスカレー ID : sho7650
  3. 3. 今日の目的とゴール 目的 インフラエンジニアの役割を知り、業界の 第一人者となるべく、知識と知恵を習得す るためのきっかけとなること ゴール インフラエンジニアのスコープを理解する インフラエンジニアとは? の問いに自分の 答えを見つける
  4. 4. 想定読者 素人 インフラエンジニアのなんたるかを、何も 知らずにこの業界に来てしまったペーペー 玄人 そんなペーペーを指導し、養っていかない とならない、自分はプロだと信じてやまな いけど、それほどでもない人たち。
  5. 5. 先に伝えておきたいこと 下書き 今日のスライドは「ドラフト」のままです。 なぜか。 他人の下書きをみることで、どのように考 え、どのように表現しようとしたか、結果 へ辿りつく重要なプロセスが垣間見えるか ら。 時間がなくて、手を抜いたわけではない。手抜きじゃない。
  6. 6. 今日の段取り Why 何故、インフラエンジニアが必要なのか What インフラエンジニアとは何か、その構成す る要素を理解して、必要性を認識する How インフラエンジニアはいかにして、インフ ラエンジニアたり得るか
  7. 7. 今日の段取り Why 何故、インフラエンジニアが必要なのか What インフラエンジニアとは何か、その構成す る要素を理解する How インフラエンジニアはいかにして、インフ ラエンジニアたり得るか このセッションでの内容 次以降のセッション
  8. 8. Why Why 何故、インフラエンジニアが必要なのか インフラ(基盤) をエンジニアリング する人が必要だから
  9. 9. 基盤をエンジニアリング するとはナニゴトか 基盤? ところで、そもそも基盤とはなんぞや 国民福祉の向上と国民経済の発展に必要な公共施設とは、学校、 病院、道路、港湾、工業用地、公営住宅、橋梁、鉄道路線、バス 路線、上水道、下水道、電気、ガス、電話などを指し、社会的経 済基盤と社会的生産基盤とを形成するものの総称である。建造物 からパイプ類、場合によっては電気機器(サーバ等のハードウェ ア)レベルが該当する。(毎度の如くWikipediaから) なにはともあれ「基盤」を理解することから始めよう
  10. 10. 基盤を構成する要素 レイヤーDC/HW/NW/OS/MW/APL インフラの領域・要素は多岐にわたる。 基盤の要素と範囲は分かった、エンジニアリングとは?
  11. 11. 基盤を構成する要素 レイヤーDC/HW/NW/OS/MW/APL インフラの領域・要素は多岐にわたる。 基盤の要素と範囲は分かった、エンジニアリングとは? 設備 ネットワーク ハードウェア オペレーティングシステム ミドルウェア アプリケーション 妥当な範囲
  12. 12. エンジニアリングとは 課題 と必要性から、世の中にある技術を組み合 わせて、最適解を導きだし、それを実現す るための活動を行うこと エンジニアリングには、技術を利用する「スキル」が必要
  13. 13. スキル? 技能 IPA のスキル標準を参考にする 一口に「インフラ」の「技術」と言っても、 それを構成するスキルは多種多様であり、 すべてを一人でまかなうことは不可能 ゆえにインフラ固有のスキルを持ったエン ジニアが必要である。 「スキル」を駆使して、どのように解を実現するのか
  14. 14. スキル? スキル IPA のスキル標準を参考にする 一口に「インフラ」の「技術」と言っても、 それを構成するスキルは多種多様であり、 すべてを一人でまかなうことは不可能 ゆえにインフラ固有のスキルを持ったエン ジニアが必要である。 「スキル」を駆使して、どのように解を実現するのか 職種 マーケティング セールス コンサルタ ント ITアーキテクト プロジェクト マネジメント ITスペシャリスト アプリケー ション スペシャリ スト ソフトウェア デベロップメント カスタマサービス ITサービス マネジメント エデュケー ション 専門分野 マ ケ テ ン グ マ ネ ジ メ ン ト 販 売 チ ネ ル 戦 略 マ ケ ト コ ミ ニ ケ シ ン 訪 問 型 コ ン サ ル テ ン グ セ ル ス 訪 問 型 製 品 セ ル ス メ デ ア 利 用 型 セ ル ス イ ン ダ ス ト リ ビ ジ ネ ス フ ン ク シ ン ア プ リ ケ シ ン ア キ テ ク チ イ ン テ グ レ シ ン ア キ テ ク チ イ ン フ ラ ス ト ラ ク チ ア キ テ ク チ シ ス テ ム 開 発 I T ア ウ ト ソ シ ン グ ネ ト ワ ク サ ビ ス ソ フ ト ウ ア 製 品 開 発 プ ラ ト フ ム ネ ト ワ ク デ タ ベ ス ア プ リ ケ シ ン 共 通 基 盤 シ ス テ ム 管 理 セ キ リ テ 業 務 シ ス テ ム 業 務 パ ケ ジ 基 本 ソ フ ト ミ ド ル ソ フ ト 応 用 ソ フ ト ハ ド ウ ア ソ フ ト ウ ア フ シ リ テ マ ネ ジ メ ン ト 運 用 管 理 シ ス テ ム 管 理 オ ペ レ シ ン サ ビ ス デ ス ク 研 修 企 画 イ ン ス ト ラ ク シ ン レベル7 レベル6 レベル5 レベル4 レベル3 レベル2 レベル1
  15. 15. スキル? スキル IPA のスキル標準を参考にする 一口に「インフラ」の「技術」と言っても、 それを構成するスキルは多種多様であり、 すべてを一人でまかなうことは不可能 ゆえにインフラ固有のスキルを持ったエン ジニアが必要である。 「スキル」を駆使して、どのように解を実現するのか 職種 マーケティング セールス コンサルタ ント ITアーキテクト プロジェクト マネジメント ITスペシャリスト アプリケー ション スペシャリ スト ソフトウェア デベロップメント カスタマサービス ITサービス マネジメント エデュケー ション 専門分野 マ ケ テ ン グ マ ネ ジ メ ン ト 販 売 チ ネ ル 戦 略 マ ケ ト コ ミ ニ ケ シ ン 訪 問 型 コ ン サ ル テ ン グ セ ル ス 訪 問 型 製 品 セ ル ス メ デ ア 利 用 型 セ ル ス イ ン ダ ス ト リ ビ ジ ネ ス フ ン ク シ ン ア プ リ ケ シ ン ア キ テ ク チ イ ン テ グ レ シ ン ア キ テ ク チ イ ン フ ラ ス ト ラ ク チ ア キ テ ク チ シ ス テ ム 開 発 I T ア ウ ト ソ シ ン グ ネ ト ワ ク サ ビ ス ソ フ ト ウ ア 製 品 開 発 プ ラ ト フ ム ネ ト ワ ク デ タ ベ ス ア プ リ ケ シ ン 共 通 基 盤 シ ス テ ム 管 理 セ キ リ テ 業 務 シ ス テ ム 業 務 パ ケ ジ 基 本 ソ フ ト ミ ド ル ソ フ ト 応 用 ソ フ ト ハ ド ウ ア ソ フ ト ウ ア フ シ リ テ マ ネ ジ メ ン ト 運 用 管 理 シ ス テ ム 管 理 オ ペ レ シ ン サ ビ ス デ ス ク 研 修 企 画 イ ン ス ト ラ ク シ ン レベル7 レベル6 レベル5 レベル4 レベル3 レベル2 レベル1
  16. 16. 構築技法 技法 過去のエンジニアが積み上げた、経験を元 に、実現可能性の高い手法を組み合わせ、 システム化(汎用的な手順や使い方を定義) したもの どのような構築技法があるのか
  17. 17. ウォーターフォールと アジャイル 2つ? ウォーターフォールをなめたらあかん。 アジャイルは銀の弾丸ではないこと、その 礎にはウォーターフォールの血があること を理解する 先人たちの知恵には、一人がいくらがん ばっても簡単に乗り越えることはできない。 あるものを再利用し、改善することが近道 ウォーターフォールのフェーズを理解しよう
  18. 18. ウォーターフォールと アジャイル 2つ? ウォーターフォールをなめたらあかん。 アジャイルは銀の弾丸ではないこと、その 礎にはウォーターフォールの血があること を理解する 先人たちの知恵には、一人がいくらがん ばっても簡単に乗り越えることはできない。 あるものを再利用し、改善することが近道 ウォーターフォールのフェーズを理解しよう 超上流 上流 中流 下流 超上流 上流 中流 下流 超上流 上流 中流 下流 超上流 上流 中流 下流 t
  19. 19. ウォーターフォール型 アプローチ フェーズEA + RD/ED/ID/CD/UT/IT/ST(UAT) これらのフェーズはどのように関係するのか
  20. 20. フェーズEA + RD/ED/ID/CD/UT/IT/ST(UAT) Enterprise Architecture ウォーターフォール型 アプローチ これらのフェーズはどのように関係するのか RD ED/ID CD/UT IT/ST ?
  21. 21. Vモデル V字? 要件定義を元に設計されたものが、正しく 実装されているかを検査する内容を定義す るためのモデル 具体的に各フェーズがどのように関係しているのだろうか
  22. 22. Vモデル V字? 要件定義を元に設計されたものが、正しく 実装されているかを検査する内容を定義す るためのモデル 具体的に各フェーズがどのように関係しているのだろうか RD ED CD UTID IT(a/b) ST(UAT)
  23. 23. EA EA? Enterprise Architecture 今日ははしょる。名前だけは覚えて帰って ください。要は企業全体で統一したシステ ム化方針を策定すること Business Architecture Data Architecture Application Architecture Technology Architecture では新しいシステムを作ろう
  24. 24. EA EA? Enterprise Architecture 今日ははしょる。名前だけは覚えて帰って ください。要は企業全体で統一したシステ ム化方針を策定すること Business Architecture Data Architecture Application Architecture Technology Architecture では新しいシステムを作ろう Technology Architecture Application Architecture Data Architecture Business Architecture
  25. 25. Requirements Definition RD? 要件定義とは 顧客の要求をまとめ、矛盾した要求がない か整理して定義し、顧客の望む要求をどの ように IT化して解決できるか、その解決策 を定める。 けして、要件をまとめるだけではない 要件は、機能要件と非機能要件とを区別し て整理する。インフラでは「非機能要件」 が重要。概算がゴール この解決策をどのように実現するのか
  26. 26. External Design ED? 外部設計では、解決策となるITシステムを 実現するためのコンポーネントを決定する 機能の配置(Concept Model) 機能+非機能=論理構成(Specified Model) 論理を実現する物理構成(Physical Model) ゴールは、金額が精緻化される (購入するHW/SW/NWが全て定まる) 各コンポーネントのパラメータはどうするべき?
  27. 27. Internal Design ID? 内部設計では、各コンポーネントが、EDで 設計したとおりに稼働するためのパラメー タまでを定義する 各サーバの各ソフトウェアの各々のパラ メータが一意に決まるように定義する ゴールは導入・設定時のパラメータをIDで 定義された結果から定義すれば良いだけの 状態 IDの結果を基に構築しよう
  28. 28. Coding/Development CD? 一般的にCD(Coding)と言われるが、これ はアプリの場合。インフラは構築 (Development,Implement)と呼ばれる。 IDで確定したパラメータを、導入手順書な どにしたがい、実際にHW/SWの導入、構 成を行う。 事前にいくら準備して検証しても、絶対に 躓いて、構成がうまくいかないのが定番。 ゴールは導入・設定が完了した状態 では、正しく構成できているか確認していきましょう
  29. 29. Unit Test UT? 単体テスト。アプリだと、一つのモジュー ル単体でのテスト。インフラでは、HW/ NW/OS/MW ごとに単体でテストする。 実施内容は、ID で定義したパラメータなど が正しく定義されているかどうかを確認す る。HWなら、指定したラックや電源、NW が差し込まれているか、OS/MWは起動す るか、起動した上で、各パラメータはIDで 決めた通りか。 ゴールは、全パラメータが正しいこと 今度は各ユニットが正しくつながるかを試しましょう
  30. 30. Integrated Test IT? 方言によってはITを分離して ITa,ITb とし ている国もあるけれども、結合テスト、を 指す。EDで設計した通りに、各サーバに配 置された各機能同士がお互いに通信できる かどうか、例えば、端末からWEBサーバの コンテンツが表示できたり、APLからDBの データが読み書きできたり。 ゴールは全ての結合が一気通貫で、全て問 題ないこと。 最後に、実際に要件を満たしているかどうかを確認しよう
  31. 31. System Test (UAT/Cyclic Test) ST? 言い方はたくさん。ともかく最終的なテス ト。要件定義で決めた一連の機能が正しく 動作するかどうか。 ユーザが購買できること(ログインして、バ スケットに商品を入れて、決裁して、発送 処理まで)を正しく、要件に従っているかど うか、実行結果は元より、画面遷移なども 含めて確認する。インフラは見守るケース が多い。 ゴールは全ての要件が満たされたこと。 全てのフェーズは完了した!?
  32. 32. Operations OP? 終わりではない。 一番重要な局面は、システムがサービスイ ンしてから。実際に利用者が使い始めてか らは、サービスが停止しないよう、データ を失わないよう、利用状況も見て、パ フォーマンスも調べて、ユーザが快適に利 用できているかどうか、常にチェックして いかなければならない。大半の人間は、こ こでしぬ体験をする。 運用の話だけで 3日寝ずに話せるので今日はしない
  33. 33. まとめ 役割 アプリがどのような挙動で動くか、把握し た上で、最適なインフラ技術を結集して、 要件(+非機能)を実現すること。 範囲 アプリ以外の全て。HW/NW/OS/MW に 対してRDからOPまで全てのフェーズでも インフラエンジニアは必要とされている。 とは? ある特定のProductだけに固執せず、イン フラ全体から見て、本当に必要なHW/SW を選択し、日々、たんたんとシステムの安 定稼働のために祈りを捧げる人たちのこと。
  34. 34. ご静聴 ありがとうございました たまには、最後に正しくまとめてみる

×