Download to read offline
Uploaded byToru Miyahara
これから始めるDevOps
2019年8月24日(土)に開催されたOpen Developers Conferenceで発表したこれから始めるDevOpsの資料です。
これから始めるDevOps
- 1.
- 2. 自己紹介 • 本名：宮原 徹 •1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 • 2000年3月 株式会社デジタルデザイン 東京支社長および株 式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 （株）デジタルデザイン、ナスダック・ジャパン上場（4764） • 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2016年ごろからDevOpsと言い始める • 2018年から自動化やDevOpsがお仕事的に少しずつ本格化 2
- 3. 日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 –英語名：VirtualTech Japan Inc. – 略称：日本仮想化技術／VTJ • 設立：2006年12月 • 資本金：3,000万円 • 売上高：11,293万円（2018年7月期） • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO） • 伊藤 宏通（取締役CTO） • スタッフ：9名（うち、7名が仮想化技術専門エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築・運用サポート – OpenStackの導入支援・新規機能開発・運用サポート – 自動化・DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 3
- 4.
- 5. 日本仮想化技術株式会社は • 仮想化技術のエキスパート集団 • 進取の精神 •豊富な検証機材で新技術を追求 • 自由な雰囲気の職場 5
- 6. 一緒に頑張ってくれる仲間を募集中 • サーバー、ネットワークエンジニア – 新卒からキャリアアップしたい経験者まで –クラウド技術、自動化技術に興味がある人 • コンサルタント – 通信系に強い人大歓迎 • インターン – 学生はもちろん、社会人も可 6
- 7.
- 8.
- 9.
- 10. 充実の福利厚生 • マッサージチェア • 充実のフリードリンクコーナー –お茶、ネスプレッソなど多種多様に取り揃え • 誕生日はケーキでお祝い • 雑誌年間購読制度 – 何でも好きな雑誌を年間購読 • 書籍購入支援制度 – 技術書の購入は無制限（当然） – 好きな書籍（漫画も可）を1万円／年購入 10
- 11.
- 12. 今日のお話の狙い • 技術的なベストプラクティスやはまりどころは お話しません • インフラ系営業・コンサルタントの立場からア ジャイル開発／DevOps案件に1年以上関 わった経験をふまえて、DevOpsを始める時の コツをお話します •ケースバイケースのことが多いので、そのあ たりは割り引いて聞いてください • 文字ばっかりで分かりにくいところはすみませ ん 12
- 13. 弊社がDevOpsに取り組む意義 • インフラ構築業務からの脱却 – 開発・テスト段階からプロジェクトに関与 –インフラ構築の継続的改善 • 新しい技術への挑戦 – 自動化の本番投入 – コンテナ、マイクロサービスの実装 • アジャイル開発への関与 13
- 14. 2018年4月 プロジェクト開始 • 業務システムのリプレース案件 –現行システムの速度が遅い – 新しい機能が追加できない – クラウド化してインフラ設備を更新したくない • アジャイル開発で順次リリースしたい – 従来はウォーターフォール型開発 – スクラムにチャレンジしたい 14
- 15. チームビルディングに苦戦 • 内製化が行えない – ≒なかなか意思決定ができない •外部開発メンバーがウォーターフォール型 開発経験者のみ – アジャイル、スクラムに初挑戦 – 仕様や設計が決まらないと始められない • 自己組織化されたチームではない – 自己組織化：課題解決の方法を自分たちで決 定する 15
- 16. スモールスタートすべきだった？ • PJ初期は意思決定と実行の速度が命 – とにかく点を取ることを目指さないと始まらない –曖昧なままスタートして、間違ってもいい – 早く失敗して、すぐ直す • 自由度は高くない方がよい？ – 言語、フレームワーク、ミドルウェア、CI/CDツー ル、チャット、チケット、ブランチ、テスト etc.. – 決めることが多すぎる – とりあえず適当な組み合わせでスタートして、後 から直す 16
- 17. 「適当」のむずかしさ • 「適当」＝「right way」 –≠「about」 • 不確定事項が多いのですべてを決められ ない – PDCAよりはOODAの方が合ってるような？ – OODA：「観察（Observe）」「仮説構築 （Orient）」「意思決定（Decide）」「実行（Act）」 • 素早い意思決定と実行のループ 17
- 18. Ops側から見たDevOps 反省点 • 「早く開発始めようぜ〜」状態からの脱却 –とにかく何か動かせる環境を早く提供する – 自動化は意識しつつ、とりあえず手作業で – 急遽始まった「動作環境準備祭り」 – KubernetesやCI/CDツールの効果的な使い方 はプロジェクトを進めながら覚えればよい • Ops側もバックログを抱えながら作業 – しかし、スクラム開発のスプリント期間に合わ せるのはなかなか難しい 18
- 19. 現在のプロジェクトの状況 • システム更改で目に見える成果が出た！ • スプリント期間2週間でのスクラム開発 –ふり返りやプランニングを隔週で交互に実施 • 開発、テスト、本番環境の自動デプロイ – ただし、完全に自動サイクルで廻すのではなく、 必要に応じて手動トリガーでのデプロイ実施 • テスト自動化への着手 – Ops側で作り込みする余地が生まれるかも 19
- 20. DevOpsをスムーズに進めるには • Dev側にインフラスキルを – Ops側にやって欲しいことが正しく伝えられる –Ops側の提案の採用可否判断ができる – チーム全員が望ましいが、無理なら1名〜2名 • 運用監視は共同で進める – Ops 6割、Dev 4割ぐらいの関与度で？ – エラー判定はOpsでは分からないことが多い 20
- 21. 最後に：やってみて感じたこと • アジャイルやスクラム、DevOpsでやること 自体を目的化してもいい – いいからやってみたらいいんじゃない？ –やってみて分かることが多い • 最初は無駄が多いのを覚悟の上で – なかなか手が動かせない時間がもったいな かった – でも、必要な初期コストだった？ 21
- 22.
- 23. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3.優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 23 自社だけではスピード感のある DevOps推進は困難
- 24.
- 25. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 • 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み •各種ツールのバージョンアップ追従 – 既存開発・運用環境からの移行支援 • 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど • 開発運用担当者の教育・サポート – 標準ドキュメント、教育コースの提供 • サンプルの提供 – 自動化・テストスクリプトのサンプル
- 26. 提供される主な機能 • チケット管理 • ソースコード管理 •テスト自動化 • デプロイ自動化 • プロジェクトマネジメント • コミュニケーション 26
- 27. サポートされる環境 • 開発：GitHub/GitLab/Jenkins/Redmine – CircleCI •構成自動化：Ansible – CloudFormation • インフラ：Kubernetis – AWS EKS • 運用監視：Prometheus – DataDog • テスト自動化：Serverspec/Selenium 27※実案件で実績あり
- 28. 改めて大募集 • 一緒にDevOpsにチャレンジする企業 – 一緒にカイゼンしていきませんか？ •一緒にDevOpsにチャレンジするエンジニア – 一緒に成長していきませんか？ – 沢山の開発者を支えるお仕事です – マジで人手が足りてません – このままだと掛け声倒れになりかねない 28
- 29.