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.

Site Reliability Engineering (SRE)を可能にするOpenPIEのご紹介

4,010 views

Published on

2016/9/12 OSS運用管理勉強会主催セミナー
クラウド時代のIT運用管理 ~OSSツールは商用ツールに追いついたか?~

Published in: Technology
  • Be the first to comment

Site Reliability Engineering (SRE)を可能にするOpenPIEのご紹介

  1. 1. Site Reliability Engineering (SRE)を 可能にするOpenPIEのご紹介 2016/9/12 http://www.ossl.co.jp TWITTER: http://twitter.com/satoruf LINKEDIN: http://jp.linkedin.com/in/satorufunai/ja SLIDESHARE: http://www.slideshare.net/sfunai FACEBOOK: http://www.facebook.com/satoru.funai 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 1 Enabling SRE 2016/9/12 OSS運⽤管理勉強会主催セミナー クラウド時代のIT運⽤管理 〜OSSツールは商⽤ツールに追いついたか?〜
  2. 2. アジェンダ 1. SREの定義 2. dev-opsとの違い 3. エンタープライズとの違い 4. 今やるべき事と理由 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 2
  3. 3. 今⽇の元ネタ 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 3
  4. 4. こちらも読んでないと、意味わからない 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 4
  5. 5. GoogleでのSREの定義 l “Fundamentally, it’s what happens when you ask a software engineer to design an operations function.” l https://landing.google.com/sre/interview/ben-treynor.html l https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre l 「SRE とは、操作機能を作ってくれとソフトウェア エンジニアに頼んだときに起こる ことだ」 l http://googlecloudplatform-japan.blogspot.jp/2016/07/sre-google-mission- control.html?1468590211542=1&m=1 l Mr. Benjamin Treynor Sloss l https://www.linkedin.com/in/benjamin-treynor-sloss-207120 l Terse variant: If Google ever stops working, it's my fault. Verbose variant : I have been responsible for global operations, networking, and production engineering at Google since 2003. As of 2016, I manage a team of approximately 4,000 software, hardware, and network engineers across the globe. Along the way, * I coined the term "Site Reliability Engineering" for my team of (now) x,xxx software engineers engaged in what were traditionally operations functions, and I have watched with some pride as the rest of the SaaS industry has adopted the SRE name, mission, and practices. * I built the networking team, from its initial scope of providing a pair of leased OC48s, to its current size -- publicly estimated to be one of the 3 largest networks in the world. * Since 2010 I've also managed datacenter design, construction and operations, and servers. Public estimates are that as of 2014 Google has built between 200MW and 680MW of highly-efficient datacenters worldwide. * Finally, since late 2013 I've been engaged on Google's public cloud product, Google Cloud Platform 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 5
  6. 6. Google SWエンジニア新卒採⽤ 必要な条件/経験 4 年制⼤学卒または関連職種での実務経験 プログラミング能⼒( 特に C++ , Java, Python) 望ましい経験/スキル 修⼠号または博⼠号を取得していること Unix / Linux または Windows 環境におけるソフ トウェア開発や API の経験 ネットワーク プログラミングやソフトウェア シ ステムの開発または設計の経験 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 6
  7. 7. 新卒SWエンジニアが配属される組織 l プロダクト&システム デベロップメント: l 検索品質を向上させる⾰新的な⽅法の発⾒、コンピューティング プラットフォームやネットワーキング技術 の構築、動画のインデックス登録の⾃動化、複雑なオークション システムの改善・拡⼤など、様々な課題に 対してソリューションを開発します。Google のプロダクトの拡⼤と品質向上を実現するためのソフトウェア アプリケーションをリサーチ、企画、開発しながら、⼤量のデータや情報アクセスに関わる問題にチームで 取り組むことが求められます。関連する専⾨分野の例として、AJAX および同様の技術を使⽤したユーザー インターフェース開発、セキュリティ、組み込みシステムとモバイルアプリ(Android および iOS)、デベ ロッパー ツール(IDE、⼤規模なビルドシステム、コンパイラ)などが挙げられます。 l エンジニアリング プロダクティビティ: l ソフトウェア設計スキル、分析⼒、プログラミング能⼒を駆使して⾰新的な⾃動テストシステムを構築しま す。これは、単なるデバッグやテストの実施といった表⾯的な作業のみを指すわけではありません。テスト チームは⽇々幅広い課題に取り組みながら、分散コンピューティング インフラストラクチャにおける多様な シナリオに対応するため、インテリジェント システムの設計と構築を担当します。これまでは存在しなかっ たものに対する⾃動テストシステムを設計、構築しようとするとき、参照できる教科書はありません。この グループで業務にあたる⼈材として Google が優秀なエンジニアを求めているのはそのためです。 l サイト リライアビリティ: l Google の製品開発プロセス全体に関与し、クラウドベース コンピューティングの最前線で業務にあたりま す。この精鋭チームの⼀員として、トラフィック異常のコードレベルのトラブルシューティングから最新 サービスのメンテナンスまで、またモニタリングやアラートから新しい⾃動化インフラストラクチャの構築 まで、Google の運営を維持するあらゆる業務に対応します。このチームのエンジニアは、何千万という数の ユーザー規模に⾒合う強靭かつ拡張可能なソフトウェアの作成に情熱を傾けています。⽇々新しく出会う 様々な事象に取り組み、ほぼすべてのエンジニアリング チームやオペレーション チームと連携して、すべて の⼈がアクセスできるような Google ならではのサービスとアプリケーションを提供します。 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 7
  8. 8. GoogleでのSREとは l 全世界に約2,000⼈(SW/NWエンジニア含めて4,000⼈) l すべての製品/サイトにSREチームがあるわけではない l 他のチームと共通採⽤、共通⼈材プール l チーム間は対等(Dev. vs Ops.ではない) l チーム間の移動は常に可能 l つまり、SREを増員すれば、開発チームはメンバーが減る l Mission Controlプログラム:製品開発に携わるエンジニアに SREの仕事を体験させる 6 か⽉のローテーション プログラム、実際に受けた⼈間の半分はSREのポジションを選択している l SREの時間の50%以上は、開発プロジェクトに当てられなければならない l 50%未満になる=運⽤/障害対応時間が50%以上になると、該当製品開発チームに負荷が割り振られる l SREの開発プロジェクトは、⾃動化や監視ツールにとどまらず、サービスレベルの向上に役⽴つもの全て(ロー ドバランサ、分散合意システム、分散スケジューリング、etc.) l サービス運⽤負荷の5%は製品開発チームが負担する l 運⽤/障害対応には、チケット処理、障害対応、オンコール(当番)が含まれる l オンコールは、8-12時間交代、時間で25%以下(1週間/⽉)、オンコール中のイベントは2件程度 l オンコールは、プライマリーとセカンダリーの⼆⼈体制で、典型的チームは8⼈体制となる l オンコールは、「新⼈の仕事ではない」。オンコールは、トレーニングとチェックリストにパスしないとできな い。 l オンコール中のSREはサービス停⽌を含む、サービスに関する全権を委譲されている。 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 8
  9. 9. SRE as a custodian “SREs are the custodian of production. SREs are the custodian of customer experience” 「SREとは、サービスとユーザー体験の 管理者であり守護者である」 How Google Does Planet-Scale Engineering for Planet-Scale Infra @ GCPNext16 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 9
  10. 10. SLAとエラーバジェット l SREチームと製品開発チーム間の契約 l エラーバジェット=100%-SLA(例:99.9%)=0.1% l エラーバジェット(=SLA)は、製品開発チームが定める l エラーバジェットを超えた場合は、製品開発チームに対応が割り 振られる l SLAを厳しくすれば、SRE対応可能時間は短くなる l 殆どのSRE対応は、新機能リリース時に発⽣する l つまり、エラーバジェットを使い果たすと、新機能リリースは凍 結せざるをえない l それを避けるためには、リリース前のレビューが重要 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 10
  11. 11. リリース前レビュー l 必ずPRR:Production Readiness Reviewが、以下の観点でSREと 開発チームで⾏われる l システムアーキテクチャー、他サービスとの依存性 l エマージェンシーレスポンス l キャパシティプランニング l 変更管理 l 計測:信頼性、応答性、リソース l PPRの中で、SLA/SLO/SLIを合意し、製品設計に必要なフィード バックを⾏い、トレーニングなどのスケジュールを決定する l SREの中には、リリース専⾨部隊(LCE: Launch Coordination Engineering)がある l 製品開発チームと協⼒して、関連するチームを横断し⾼品質な製品リリースに 向けてコンサルテーションを⾏う l Google検索から、Andoroidアプリまで全てのGoogle製品に関わる l もし製品開発チームと合意できなければ、 SREは断れる2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 11
  12. 12. Launch Coordination Checklist例 l アーキテクチャー l アーキテクチャー概要 l クライアントからのリクエスト(API) l マシン/データセンター l 使⽤リソース、帯域幅、データセンター l 冗⻑性、QoS l DNS、ロードバランス l キャパシティプランニングと性能予測 l トラフィック予想 l 負荷テスト結果、最⼤応答性能/データセンター l 他サービスへの影響 l ストレージ容量予想 l 冗⻑化とフェイルオーバー l サーバー/ラック/クラスター障害発⽣時の挙動 l データセンター間NW障害時の挙動 l バックエンドサービス障害時の挙動 l 障害発⽣時の再起動/回復の⼿順 l バックアップ/リストア/DR回復⼿順 l 監視と運⽤ l 内部状態の監視と外部からの監視、アラートの設計 l 監視システムの監視 l ビジネス的に重要なアラートとログの定義 l アラートメール攻撃の回避 l セキュリティ l スパム対策、脆弱性対策、認証認可設定 l リリース前のアクセス制御、ブラックリスト設定 l ⾃動化とマニュアルタスク l 変更管理/プロビジョニング⼿順 l リリース⼿順、継続的ビルド/デプロイ⼿順、カナ リー/ステージドロールアウト⼿順 l スケーリング l スペアリソース、バースト対応、あらーちょ l スケーリングのボトルネック、HW/キャッシュ/ データ分割⽅法 l 外部依存性 l 依存外部システムのキャパシティ l 外部サービス容量超過時のデグレード⽅法 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 12
  13. 13. Postmortem Culture l 直訳では検死報告書、障害報告書であるが、内部資料 l Blame-freeポリシー: l ⼈やチームを咎めない l 現象と経過、対応内容と結果を記録し、共有するのが⽬的 l 典型的には下記のような障害発⽣、サービス回復後に作成 l ユーザーに影響のあるサービス障害 l データ喪失 l オンコールエンジニアが対応した障害 l 回復に想定以上の時間がかかった場合 l 監視に関する障害により、マニュアル作業が発⽣した場合 (オンコールエンジニアにエスカレーションされな かった) l 障害発⽣中の対応(chat/mail etc.)はすべて記録されなければならず、Postmortemに反 映される l Postmortemを書くのは、新⼈の仕事ではない l 新⼈教育は、Postmortemを読むことから始まり、Postmortemをベースとしたロールプ レイトレーニングが実施される l Postmortem勉強会が常に開催され、優れたPostmortemを書いたエンジニアは、勉強会 の講師となり尊敬される 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 13
  14. 14. Postmortem例 l インシデント#465 l XXシステムPostmortem l 報告年⽉⽇: l 著者: l ステータス: l 完了、アクションアイテム作業中 l 要約: l アクセスピーク時間中に66分間XXシステムサイトサイトダ ウン l 影響: l 約12億ビューの喪失、売上への影響はなし l 根本原因: l ⾼負荷のためにメモリリークによるリソース不⾜が発⽣し、 ネットワーク負荷が上がった複合障害 l トリガー: l XXモジュールの潜在バグ l 解決策: l トラフィックをリソースを10倍に増やしたクラスターにリ ダイレクトし、負荷を緩和 l 監視結果: l Hhttpp500エラーの多発のため、アラート発報 l アクションアイテム: l 項⽬、タイプ、担当者、チケット番号 l Lessons Learned l 何がうまくいったか l 監視システムが正常にエラー検出しアラートを発報 l 何がうまくいかなかったか l 初めて経験した複合障害のため、障害原因特定に時間がか かった l 幸運だった点 l バックアップが残っていた l 経過詳細: l 時間、現象、対応 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 14
  15. 15. インシデントレスポンス l ICS: Incident Command Systemがベース l https://en.wikipedia.org/wiki/Incident_Command_System l http://www.bousai.go.jp/kaigirep/kentokai/kentokaigi/04/pdf/shiryo1.pdf l ⽶国で開発された包括的な危機管理体系であり、種類・規模・場所・複雑さ、あらゆる組織に適⽤できる危機管理の考え⽅、 原則を整理したもの l 危機管理の標準化(語彙と意味、組織、権限、⼿順など)により、災害対応従事者の協⼒と相互運⽤性を向上させる l インシデントレスポンスでは、状況に応じて下記の役割を割りあてる l インシデントコマンダー:指揮調整者 l オペレーショナルワーク:実際にシステム変更作業を⾏うチーム、他の担当者は操作を許されない l コミュニケーション:記録と関係者への報告 l プランニング:オペレーショナルワークをサポートするための各種⼿配、交代要員調整 l コミュニケーションツール l 必ず記録が残るように、メールやIRCなどのチャットツールを使う、Googleではトピックやログを⾃動収集するボットも使⽤ l ライブドキュメント:関係者が誰でも読み書きできる掲⽰板、Google Docsなど l 明確な引き継ぎ:誰もがわかるように、内容と業務を明確に引き継ぐ l インシデントレスポンスのベストプラクティス l 優先順位:⽌⾎、回復、証拠保全 l 準備:インシデントレスポンス⼿順の標準化と⽂書化、トレーニング l 信頼:対応チームメンバーへの信頼と委任 l 内省:パニックになる前に、⽀援を依頼する l 選択肢の考慮:定期的に選択肢を再検討する l 演習:⾃然に体が動くまで演習を⾏う l 役割交代:すべてのメンバーがすべての役割をこなせるように、都度役割は交代する 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 15
  16. 16. ⽂書化⼤事 l 優秀なエンジニアは、ドキュメント化しなければなら ない l 知識と技術を暗黙知から、共有し活⽤される知識に変 えるのがドキュメント化 l Postmortemだけでなく、チェックリストやマニュアル など、常にレビュー/アップデートが⾏われる l そのためのミーティングも重視されている l 記録するだけでなく、検索や集計など再利⽤できるこ とが重要 l 勘と度胸の運⽤ではなく、計測とデータによる運⽤ 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 16
  17. 17. アジェンダ 1. SREの定義 2. dev-opsとの違い 3. エンタープライズとの違い 4. 今やるべき事と理由 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 17
  18. 18. DevOpsとは l 「DevOpsとは開発と運⽤が協⼒し、ビジネスリスク を軽減する」 l http://www.publickey1.jp/blog/11/devops.html l 初出は、2009年に⾏われた「Velocity 2009」というイ ベントでFlickrのスタッフが⾏ったプレゼンテーション 「10 deploys per day : Dev&Ops cooperation at Flickr」らしい。(https://ja.wikipedia.org/wiki/DevOps) l http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and- ops-cooperation-at-flickr l この時点では、GoogleはSREを始めて既に6年経過し ていたが、対外的な積極的発信はしていなかった 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 18
  19. 19. 「10 deploys per day」から引⽤ DevOpsとは、 1. ⾃動化されたインフラ 2. 共有バージョン管理 3. ワンステップビルドとデプロイ 4. 機能フラグによるリリース機能制 限 5. DevとOpsの共有メトリクス 6. IRCとIMロボット ⽂化 1. 尊敬 2. 信頼 3. 障害への健全な姿勢 4. ⼈のせいにしない 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 19
  20. 20. SREにあって、DevOpsにないもの l ⽂書化 l コミュニケーション l レビュー l エラーバジェットやPRR、Postmotern、ICSなどの仕 組み 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 20
  21. 21. シスアド vs DevOps vs SRE? l シスアド:何らかの⽬的のためにシステムを設計、構 築、正常運転維持、予防保全を⾏う l DevOps:同上 l SRE:同上 l 違いは対象とするもの l シスアド:⼀度構築したら⼤きな変化はないシステム l DevOps:常に迅速な変化が要求されるシステム l SRE:Google 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 21
  22. 22. アジェンダ 1. SREの定義 2. dev-opsとの違い 3. エンタープライズとの違い 4. 今やるべき事と理由 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 22
  23. 23. Googleスケール l 2015年度実績 l 売上⾼$74,541M l 営業利益$23,425M l 営業利益率31% l 従業員数約6万⼈ l 従業員あたり営業利益$390K l 全世界84オフィス l Fortune500の売上⾼94位 l IBM 84位、ソフトバンク92位 l 全世界に15ヶ所(2016/7現在)のDC l 1ヶ所あたり10万〜40万台、合計4 00万台?以上のサーバー(推測) l 内製HW/SW l グローバルSDN WAN 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 23http://toyokeizai.net/articles/-/64182?page=2
  24. 24. ⽇本のエンタープライズ環境 l スケール:多くて2,000 - 3,000台のサーバ l SW/HW/NW:各ベンダーから調達、異種混在環境 l 体制:システム部 -> システム⼦会社 -> Sier -> 2次請 -> 以下⾃粛 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 24
  25. 25. 結論 我々はGoogleにはなれない しかし、知⾒は活⽤できる 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 25
  26. 26. アジェンダ 1. SREの定義 2. dev-opsとの違い 3. エンタープライズとの違い 4. 今やるべき事と理由 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 26
  27. 27. エンタープライズIT l 広告/ゲーム/Web系とは別世界 l 変化しないシステムと変化するシステムの両極分化 l 情報システム部⾨無⽤論 l 全体的にも、変化速度がゆっくりと増えて⾏く l 古い酒を新しい器に⼊れるような仕事が増える l 複雑さが増し、従来の運⽤は破綻する l しかし予算は減らされる 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 27
  28. 28. 今やるべき事:現場 l 開発部⾨も運⽤部⾨も l Excel/Word/Powerpointの⼿順書はコード化 l コード化すれば、ドキュメントを⽣成する⽅法はある l コーディング/レビュー/テストを、運⽤と開発で 共通化標準化 l 計測し、記録し、⽂書化し、共有知化する仕組 みを作る l 記録するだけでなく、検索や集計など再利⽤できることが重要 l 勘と度胸の運⽤ではなく、計測とデータによる運⽤ 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 28
  29. 29. SREを実現する l OpenPIEの⽬的は運⽤⾃動化そのものではなく、 すべてのオペレーション、機器情報や障害対応を 記録し、情報共有・分析によるSRE (Site Reliability Engineering)を可能にすることです。
  30. 30. SREを実現する l 運⽤ポータル: l Liferayポートレットにより必要な情報が⼀覧でき、表⽰情報はユーザー⾃⾝でカスタ マイズ可能です l プロビジョニング: l Excelで作成した設定シートをアップロードするだけで、⾃動的にサーバーを作成し アプリケーションをインストール・設定します l インベントリ収集/構成管理: l 管理対象機器から、構成情報を⾃動収集します l システム監視: l プロビジョニングされたシステムを、⾃動的に監視開始します l アラート⾃動対応: l システム監視が発報したアラートから⾃動的にチケットを作成し、予め登録した⼿順 に従い対象システムにログイン・ログ収集・プロセス再起動などを実⾏します。
  31. 31. 運⽤管理⾃動化製品例 運用ポータル ジョブモニタ リソースモニタ チケットモニタ カレンダ イベントモニタ ニュース 監視/アラート サービスデスク/ 構成管理/変更管理 チケット作成 障害通知 プロジェクト管理作業依頼 ソースコード管理 コード 作成/修正 デプロイツール ジョブ管理 クラウドAPI テスト デバッグ リリース クラウド プロバイダ リソース結果登録 オーケストレーショ ンレイヤ イメージ置場 レポジトリ CMDB メール 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 31
  32. 32. ネットワーク管理 アプリケーション フレームワーク 監視 資源管理 (クラウド/VM/実機/ストレー ジ) OSインストール 初期設定/構成管理 アプリケーション構成 コマンド⾃動実⾏ openQRM CMDBuild Kubernetes GlusterFS Ceph XtreemFS Puppet Ansible Nagios Zabbix Fabric 運⽤管理⾃動化OSSツール JobScheduler Open Contrail Etc. ジョブ管理 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 32 サービスデスク/⼯程管理/リポジトリ Redmine Git/svn OTRS
  33. 33. Open Programmable Infrastructure Environment バージョン管理 サービスデスク 運⽤ポータル 設定シート アップロード ミドルウェア/ア プリ 構成管理 実⾏管理 システム監視 vmware プロビジョニング 物理サーバ インベントリ収集 パラメータ作 成 Apply /Destroy コマンド実⾏ チケット ⽣成 監視設定
  34. 34. ツールの選択 l エコシステム l 情報量 l コミュニティ l 商⽤サポート l ⽇本語サポート l 国際化(i18n)対応 l ドキュメント l API l 外部API(SOAP/Rest) l 内部API(Java/Java Script/Python/Ruby/Perl/Php etc.) 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 34
  35. 35. ⾃動化の鍵:ワークフロー制御 l ⼈間判断フロー:Enhydra Shark l 承認、指⽰など各ステークホルダが⼊⼒ l プログラム制御:JobScheduler l エラー制御、分岐判断のロジックを記述 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 35
  36. 36. ジョブ管理:JobSchedulerの特⻑ l オープンソース(GNU Public License V.2) l Linux/Windows版は、全ての機能が無料で使⽤可能。 l サポートライセンスを購⼊すれば、HP-UX/Solaris/AIX版の利⽤に加えて、障害対応、 バグフィックス/ワークアラウンドの提供、新機能の早期提供、チケットシステム (OTRS)、JIRAの利⽤が提供される。 l プログラマブル l ジョブの中で、Java, Perl, JavaScript, VBScript, Powershell, javax.scriptの内部APIを 使ったロジックを記述可能 l 外部API(XML形式)によりRESTまたはコマンドラインからジョブの実⾏制御、実⾏ 状況の取得が可能 l エンタープライズ・グレード l ファイル転送やログローテンション等豊富なテンプレート機能 l リモートジョブ実⾏、冗⻑化機能、ロードバランス、外部認証等、エンタープライズ 向け⼤規模システム対応 l JasperReport(ジョブ実⾏レポート)やZabbix/Nagios(ジョブ実⾏監視)との連携機 能 l MySQLの他、PostgreSQL, Oracle, DB2, MS SQL Server, Firebirdに対応 l 豊富な導⼊実績2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 36
  37. 37. JobScheduler V.1.11ジョブフロー画⾯
  38. 38. CMDBuild構成管理システム l 2005年プロジェクト開始 l 伊Tecnoteca 社が開発、AGPLライセンス l http://www.cmdbuild.org/ 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 38 CMDB インベントリ収集 ワークフロー 文書管理 地理情報 レポーティング API JSON/SOAP APACHE TOMCAT アセット コンピュータ ライセンス サーバ デスクトップ ユーザ サプライヤ ドキュメント 場所 保守契約 監視システム ポータル
  39. 39. ワークフロー機能 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 39 l Together Workflow Editorで作成したワークフローを、インポート http://www.together.at/prod/workflow/twe Redmine'>) Cmdbuild) ) ) or Redmine Redmine XRFC X X X ) )X Redmine) ) ) X X X RFC01 RFC02 RFC03 RFC04 RFC05 RFC00 RFC06 RFC07 RFC08 RFC09 RFC10 RFC11 RFC12 RFC13 RFC14 )
  40. 40. ⾃動インベントリ収集 l エージェントレス型 l nmap, snmp, ssh, WMIによる、Linux/Windows/NW機器の情報収集 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 40
  41. 41. プロビジョニング⾃動化例 サーバ構築依頼 受付 変更依頼 チケット発⾏ 影響調査 変更承認 作業指⽰ サーバ構築 構築検証 監視設定作業結果承認 CMDB登録 インベントリ収集 チケット クローズ ヒヤリン グシート 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 41
  42. 42. インシデント対応⾃動化例 アラート発報 受付 チケット発⾏ 影響調査 変更承認 作業指⽰ バージョンアップ 構築検証作業結果承認 ⼀次切り分け 変更依頼 CMDB登録 インベントリ収集 チケット クローズ 2016/9/12 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 42
  43. 43. ヒヤリングシート例 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 43
  44. 44. Githubで公開中 https://github.com/oss-laboratries/OpenPIE
  45. 45. 参考資料 l Site Reliability Engineering - How Google Runs Production Systems l https://www.amazon.co.jp/Site-Reliability-Engineering-Production-Systems/dp/149192912X l クラウドを⽀える技術 ―データセンターサイズのマシン設計法⼊⾨ l https://www.amazon.co.jp/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6% 8A%80%E8%A1%93- %E2%80%95%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC%E3%82%B5%E3%82%A4%E3 %82%BA%E3%81%AE%E3%83%9E%E3%82%B7%E3%83%B3%E8%A8%AD%E8%A8%88%E6%B3%95%E5%85%A5%E9%96%80-WEB- PRESS-plus/dp/4774167304/ref=sr_1_sc_2?ie=UTF8&qid=1468737268&sr=8-2-spell&keywords=datacenter+as+acomputer l What is ‘Site Reliability Engineering’? l https://landing.google.com/sre/interview/ben-treynor.html l Keys to SRE Presentation by Ben Treynor @ SREcon14 l https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre l How Google Does Planet-Scale Engineering for Planet-Scale Infra @ GCPNext16 l https://youtu.be/H4vMcD7zKM0 l Love DevOps? Wait 'till you meet SRE l https://www.atlassian.com/it-service/site-reliability-engineering-sre l Hiring Site Reliability Engineers l https://www.usenix.org/system/files/login/articles/login_june_07_jones.pdf l The Systems Engineering Side of SiteReliability Engineering l https://www.usenix.org/system/files/login/articles/login_june_08_hixson.pdf l Weathering the Unexpected l http://delivery.acm.org/10.1145/2380000/2371516/p30-krishnan.pdf l Borg, Omega, and Kubernetes l http://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/44843.pdf 2016/9/1 Copyright 2016(C) OSS Laboratories Inc. All Rights Reserved 46

×