DevOps 用語の備忘録

はじめに

上記の書籍でモダンな開発手法についてまとめた備忘録です。メモ程度に、、、
ユーザ(運用側)が求めているシステムを考慮しつつ、開発効率をあげるみたいな観点で調査したつもりです。。

書籍以外の参考
https://licensecounter.jp/azure/blog/topics/20180223.html

開発の問題点

• 開発プロセスを重視して、運用の仕事が切り離される。開発以外のチームに特定の手法を強制する。
• DevOpsは開発（Development）と運用（Operations）の頭文字を取った言葉で、開発担当者と運用担当者が密接に連携し、要求に対して迅速かつ柔軟に対応できる仕組み作りをしようという考え方。
• 開発チームと運用チームの衝突は珍しいことではなく、最近のシステム開発では小さな開発サイクルを繰り返すことが多いため、開発チームは常に改善や修正を繰り返すことに目が向く。一方、運用チームにとっての最優先課題はシステムの安定稼働なので、システムに致命的な問題さえなければ手を入れたくないと運用チームが考えるのはごく自然なこと。その結果、相反する考えを持つ両者は衝突にいたるというわけで、これは現在のシステム開発の現場にとって、大きな損失となる。
• そこで、開発チームと運用チームの両者が開発に関わることで衝突を避け、新たなシステムの要求から実装に至るまでの時間を短くすることがDevOpsが目指すもの。

ソフトウェア開発のこれまで

• water fall ウォーターフォール
  - 要件定義
  - 概要設計
  - 詳細設計
  - 開発
  - テスト
  - 運用
  といった各工程にわけて直線的に結合し、前の工程のドキュメント作成などを完了してから次の工程に入る、といったスタイルで運用していきます。原則的に手前の工程で決めたことを尊重して、戻り作業を発生させないという考え方です。

  • ハードウェア工学で採用されていた（製造業、建築業で生まれた）。1980にソフトウェアに取り入れた
  • 元々ソフトウェアはCDROMで流通してたので、修正して再配布するのはコストがかかるから、はじめからしっかり要件を定義して作る必要があった。

• Agile アジャイル

  • 2001のアジャイルマニュフェストで原則ができた
  • 機能ごとに計画からテストまで行う「イテレーション」というサイクルを繰り返しながら、全体の開発を進めていく。ウォーターフォールに比べて、仕様で決めた実物をいち早く確認することもできる。
  • 人、対話、コラボレーション(開発側と運用側の協力)を強調している。これはDevOpsとも共通

• スクラム

  • アジャイルの一種
  • スプリントと呼ばれる。1- 4週間のサイクルを繰り返す。
    • スプリントランニング:目標設定
    • スプリントレビュー:達成した成果を確認
    • スプリントレトロスペクティ:スプリント中の問題点を議論
  • デイリースクラム:立ったまま行うミーティング。メンバーは3つの質問に答える。
    • チームが、スプリントの目標を達成するために、昨日何をしたか
    • チームが、スプリントの目標を達成するために、今日何をするか
    • 目標達成の妨げとなるものは何か
  • チームリーダーはスクラムマスターと言われる

• DevOps

  • 開発チームと運用チームの両者が開発に関わることで衝突を避け、新たなシステムの要求から実装に至るまでの時間を短くすることがDevOpsが目指すもの。
  • DevOpsでは具体的な開発手法より情報の共有ツールやテストツール、自動化の仕組みなどがフォーカスされやすい。それらの個々のツールが大切なのはもちろんだが、最終的にはビジネスのスピードアップに対応できる組織と仕組みを作る、ボトルネックを把握するというところを意識することが肝心。

運用手法例

運用側が気にすることの事例集みたいな、成功事例のようなもの

• ITIL information technology infrastructure library
  • itサービス管理のためのプラクティス集。
    • プロセス
    • 手順
    • タスク　
    • チェックリスト 　　　　　　　　上記などをまとめた。1980くらいit組織が増えたからできた。
  • 最新版は2011で。サービス戦略、サービス設計、サービスの変遷、サービスの運営、継続的なサービスをコアセクションにしてる。資格とかもある
• COBIT control objective for information and related technology
  • ISACA（情報システムコントロール協会）が1996にリリースした情報と技術のgovernance（統治のあらゆるプロセスを言う）と管理のフレームワーク。
  • 5つの原則がある
    • ステークホルダーのニーズに応える　利害関係者
    • 企業全体をカバーする
    • ひとつに統合されたフレームワークを適用する
    • 包括的なアプローチを実現する
    • ガバナンスとマネジメントを分離する

開発、リリース、デプロイの諸概念

開発を効率化するための考え方

• バージョン管理

  • バージョン管理を表す英語⇨SCM(software control management) , revision control , version control , source control ,,etc
  • ひとつまたは複数ファイルに対する変更を記録するのに使う
  • 対象は、ソースコード、asset（資材、ソフトウェア、ライセンスなど）、ドキュメント、など。
  • 一度に行った変更の集合をコミット、revison（修正したときの版数）という。
  • バージョン管理システムを使うと、本番環境のオブジェクトを前のバージョンに戻せるのでリスクは最小になる。

• TDD test driven development　テスト駆動開発

  • 開発者はまず新しいコードのために失敗するテストを作る。その後にコード自体をかいて、最後にコードが完成したらテストする。テストを先に書くと、新しい機能を明確に定義できるし、コードが行うべきことがはっきりする。
  • 開発者自身がテストを書くことで、フィードバックループが大幅に短縮される。また開発者が自分の書いたコードに責任をもつようになる。責任の共有と開発サイクルの時短ができる。これはDevOpsと共通する。

• デプロイ

  • デプロイとはソフトウェアリリースの計画作り、リリース実行、保守を含むプロセスを指す。
  • システムの依存部分を自動で構築すると、依存部分の不一致が与える影響を最小化できる。（Chef:インフラストラクチャー自動化）
  • データベースのデプロイでは厳格な整合性保証が必要になる。
  • アプリケーションのデプロイは、高品質なソフトウェアの実現に極めて重要。

• CI continuous integration 継続的統合

  • 開発者が書いたコードとマスターブランチを頻繁に統合するプロセス
  • CIシステムは統合の成功を確認するため、新しい変更のたびにテストを自動実行する。
  • テスト結果は可視化される、緑はok 赤はビルドに問題あり

• CD continunous delivery　継続的デリバリー

  • ソフトウェア工学の一般的な原則を集めたもの
  • 自動テストとCIを活用して、新しいソフトウェアを頻繁にリリースできるようにする。
  • 新たな変更をしても自動テストが失敗しないようにするだけでなく、変更をデプロイ可能にすることがCDだとされてる。

• CD continunous deploy 継続的デプロイ

  • 変更を本番環境にデプロイするプロセスのこと。
  • 継続的デリバリーではデプロイ可能にするまでだったけど、本番環境に実際にデプロイするのが、継続的デプロイ。
  • デプロイが早くなるので、顧客満足度、開発者の達成感も向上する

• 継続的デリバリーと継続的デプロイについて

  • デプロイはウェブアプリケーション特有だが、デリバリーはIotや組み込みソフトウェアを含む、あらゆるソフトウェア開発プロジェクトに応用可能な一般的な原則の集合を指す。

• MVP minimum viable product 実用最小限の製品

  • リーンと同じように、はじめから100%の製品を作るのでなく、リリースしてからユーザーの使用に応じて変更を加えることで、開発のコストを削減するもの。また顧客のニーズに合わないものを提供するリスクも減る。

• infrastructure

  • 自社のサーバだけでなく、SaaS PaaS IaaS などインフラの概念が広がっている。スケーリングの変化も

• CM configration manegiment 構成管理

  • システムのライフサイクルをインフラ、フロント、エンドまで一貫性を維持するプロセス。
  • Chef バージョン管理 provisioning（インフラのスケーリングを考慮して予備を持っておくこと？）とは区別されないで使われる。

• クラウド　cloud computing

  • インターネット経由の共有型のコンピューティングのこと

• Chef

  • システムを構築する方法の一つ
  • 自動化により作業時間を軽減（例　会社の全てのサーバにコマンドを手作業で実行するのでなく、1ステップで実行できるシェルスクリプトにそれらのコマンドをまとめるのが自動化）

• Artifact管理　
  • リポジトリ管理のこと？
  • artifactとは開発プロセスの様々なステップでの成果物のこと、
  • Artifactの例
    • JAR（JAVA archive：javaのコンパイルされた複数のjavaバイトコードと使用画像などのリソースを１つにまとめたzip形式のファイル）
    • WAR（web application archive：javaのクラスファイル、JAR形式のアーカイブファイル、設定ファイル、JSPページ、HTMLページなどの関連する複数ファイルを１つにまとめている。JAVA EE で開発されたWebアプリケーションを１つのファイルにパッケージする標準的な方法である）
    • ライブラリ（汎用性の高い複数のプログラムを再利用可能な形でひとまとまりにしたもの。）
    • asset（資材、開発コスト、ライセンス、、etc）
    • アプリケーション
  • アーティファクト管理の役割
    • バイナリや依存コードを管理するためのコア
    • 企業と公開リポジトリ間のプロキシ
    • ビルド昇格したソフトウェアの保存
• container コンテナ
  • コードの変更を速やかに反映する方法である
  • コンテナは隔離されていて、土台のOSやハードウェアに比較的依存しない形で開発やデプロイが可能である。
  • コンテナは仮想マシンと同じで、その中で実行されるコードをサンドボックス化（sandbox：外部から受け取ったプログラムを保護された領域で動作させることでシステムの不正操作を防ぐセキュリティ機構のこと）するための方法である。
  • ローカル環境のコンテナで開発を行いアプリケーションを作成し、同一コンテナを本番環境にデブロイするのは比較的に簡単である。

最後に

本書籍で取り上げているDevOpsは開発手法だけでなく、開発に対する考え方の重要性にも重点を置いているのでそのまとめ。

• レトロスペクティブretrospective：プロジェクト終了後に行われる議論のこと。
  • プロジェクトでうまく機能したことや、改善すべきことを検討する。
  • レトロスペクティブは定期的に行う。目標はローカル学習（個人やチーム単位）。プロジェクトの成功・失敗を将来のプロジェクトに活かすためである。
  • レトロスペクティブのスタイルは色々だが、通常は次のテーマをあつかう
    • 何が起きたか：プロジェクトの範囲で完成したものは何か
    • うまくいったことはなにか：うまくいったやり方、チームが誇りに思う部分は？、将来のプロジェクトで使うべきものは？
    • 失敗したことは何か：うまくいかなかったことは何か、発生したバグにどんなものがあったか、納期を守れなかったものは？将来のプロジェクトで避けるべきものは？
• ポストモーテムpost- mortem
  • レトロスペクティブとは異なり、計画的には行わない。イベントが発生したら行う。
  • プロジェクトによって生み出されたシステムに想定外のincident（出来事）が起きた時や、サービス障害が起きた時にその結果が、関係者にとって意外でシステムや組織の欠陥が少なくとも１つは明らかになったときポストモーテムは行われる。
  • 目的は全体規模の学習（会社）
  • 下記のようなテーマを取り上げて、体系的で一貫性のある方法（どんな方法だよ？）で議論を進めると効果的である。
    • なにが起きたのか：incidentの最初から最後までのタイムライン。コミュニケーションの内容やシステムのエラーログも含む。（洗い出しって感じ？）
    • 報告：inceidentに関わった全てのメンバが事象発生中に考えたことやincidentについての自分の考えを提出する。
    • 改善事項：システムの安全性を高め、再発を防ぐために変えなければいけないこと（これがわかれば苦労しないでしょ？）
  • DevOpsではretrospectiveとpost- mortemを非難なしで行うことを説いている。(これ重要)
• 非難のない文化
  • シドニー・デッカー
  • ジョン・アレスポウhttps://codeascraft.com/2012/05/22/blameless- postmortems/
  • incidentの振り返るには懲罰ではなく学習に重点をおく
• 組織的な学習
  • 組織的学習とは「組織の持つ知識を集約して、成長させ、共有するプロセス」である。
  • 学習する組織とは学習を意識的におこない、学習を具体的な目標として掲げ、時間とともに蓄積された学習量を増やしていくために具体的な活動をしている組織である。