DevOps Glossary of Terms

DevOps関連の用語集

A~Zまで、DevOps関連の役に立つ用語を集めたものです。

A/B Testing

新しい機能または機能のさまざまなバリエーションをさまざまなユーザーのセットで利用可能にし、メトリックとユーザーのビヘイビアを比較することで評価する方法。

Acceptance Testing

通常、新機能と既存の機能の両方の全体的な品質がシステムを実稼働させるのに十分かどうかを判断するためのシステム全体のハイレベルなテスト。

Agile

DevOpsの前身。 アジャイルはソフトウェア開発であり、より広くはビジネス手法であり、短い反復計画と開発サイクルを重視して、コントロールと予測可能性を改善し、プロジェクトの進化に伴うリクエストの変更に対応します。

Application Release Orchestration (ARO)

ツール、スクリプト、商品など、自動的にインストールされ、準備万端のターゲットの環境において、アプリケーションの特定のバージョンを適切にコンフィギュアします。また、これは、「Application Release Automation：アプリケーション リリースの自動化」（ARA）、もしくは「継続的デリバリとRelease Automation：リリースの自動化」(CDRA)よも呼ばれます。

Behavior-Driven Development (BDD)

ソフトウェアをアサートする開発方法論は、アプリケーションの望ましいビヘイビアの観点から、ビジネスマネージャーが読み取り可能なsyntax（構文）で指定される必要があります。

Black Box Testing

テスト対象のシステムの内部動作に関する知識がないことを前提とするテスト、または品質保証プラクティス。したがって、内部のビヘイビアや状態ではなく外部の検証を試みます。

Blueprints

Blueprintを使用することで、企業全体のプロジェクト、アプリケーション、チームをDevOpsツールチェーンに組み込むことができ、多くの管理費用もそこまで多くかかりません。

Build Agent

Continuous Integration（継続的インテグレーション：CI）サーバーに対してローカルまたはリモートでインストールできるContinuous Integration（継続的インテグレーション：CI）で使用されるエージェントのタイプ。 ソフトウェアビルドの処理に関するメッセージを送受信します。

Build Artifact Repository

メタデータ構造を持つアーティファクトを整理し、それらのアーティファクトの自動公開と消費を可能にするために使用されるツール。

Build Automation

ソースコードをリリース可能なバイナリに自動的にコンパイルできるツールまたはフレームワーク。 通常、コードの個々の部分が期待どおりに動作することを確認するためのコードレベルのunit testが含まれています。

Canary Release

新しいアプリケーションバージョンが運用サーバーの小さなサブセットにリリースされ、期待どおりのビヘイビアをするかどうかを判断するために厳重に監視される本番稼働戦略。 すべてが安定しているようであれば、新しいバージョンは運用環境全体にロールアウトされます。

Configuration Drift

ソフトウェアおよびハードウェアのコンフィグレーションがdriftする一般的な傾向を表す用語。（hotfixesのような）テンプレートに導入されない手動のアドホックな変更が原因となり、システムのテンプレートバージョンを伴う一貫性のないものになることもあります。

Configuration Management

システムの一貫した設定と機能的属性を確立および維持するための用語。 ITインフラストラクチャの自動化などのような、システムアドミニストレーションタスク用のツールが含まれています。

Container

containerは仮想マシンに似ていますが、仮想マシンよりも軽量です。コード、ランタイム、システムツール、システムライブラリ、設定など、ソフトウェアの実行に必要なすべてを含む他に類を見ない実行可能パッケージです。

Continuous Delivery (CD)

ソフトウェア生産プロセスから徹底的に無駄を取り除き、高品質の機能を迅速に提供し、ビジネスとユーザーの間に迅速かつ効果的なフィードバックループを設定する一連のプロセスとプラクティス。

Continuous Integration (CI)

開発者が1日に数回、コードを共有リポジトリに統合する必要がある開発手段。 各チェックインはautomated buildによって検証され、チームが問題を早期に検出できるようにします。

Dark Launch

新機能を実装するコードが実稼働環境のサブセットにリリースされますが、目に見えて（または部分的にのみ）アクティブ化されない本番稼働戦略。 ただし、ユーザーが気付かないうちに、本番環境でコードが実行されます。

Delivery Pipeline

新しいアプリケーションバージョンのソフトウェアのデリバリプロセスを実装する、オーケストレーションされ、自動化されたタスクのシーケンス。 パイプラインにおける各ステップは、新しいバージョンの信頼レベルを上げて、go/no-goの決定ができるようにすることを目的としています。delivery pipelineは、組織のリリースプロセスを最適化した結果と考えることができます。

Deployment Automation

SDLCで使用されるさまざまな環境へのアプリケーションとコンフィグレーションの合理化。deployment automationソリューションを使用することにより、チームは継続的な統合や環境のプロビジョニング、およびテストのための安全なセルフサービスデプロイメント機能が確実に手に入れることができます。deployment automationソリューションは、デプロイメントのエラーや不具合の割合を大幅に削減しながら、より頻繁にデプロイメントするのに役立ちます。

DevOps — Development + Operations

開発（Development）と運用（Operations）という言葉を二つ合わせた新しい言葉であるDevOpsは、ソフトウェア開発サイクルのさまざまなロール間のコミュニケーション、コラボレーション、プロセスを改善する一連のプロセス、プラクティス、およびツールであり、より優れたソフトウェアを迅速かつ安定的に提供します。

DevOps Intelligence

企業環境でのソフトウェアデリバリーには、さまざまな機能的なチームと機能的なツールが含まれます。 ソフトウェアデリバリプロセスをend to endで改善するには、デリバリパイプラインのすべての部分からのデータを分析および相関させる必要があります。 DevOps Intelligenceツールは、この可視性を可能にし、過去のアクティビティの詳細なメトリック、現在のステータスへのリアルタイムの可視性、洞察に富んだ分析を組み合わせて、問題の早期の警告を発してくれ、そして将来のパフォーマンスを予測します。

DevSecOps

セキュリティをDevOpsプロセスに統合する方法。

Everything as Code

ソフトウェアの構築と配信に必要なすべてのコンポーネント（デプロイメントパッケージ、インフラストラクチャー、環境、リリーステンプレート、ダッシュボード）がコードとして設定される開発手法を指します。 デリバリパイプラインをコードとして設定すると、オンボードのプロジェクト、アプリケーション、およびチームへの標準化された、そしてコントロールされた方法が取れます。

Feedback Loops

ソフトウェア配信プロセスの早い段階で運用（Operations）と開発（Development）の間で迅速かつ継続的なフィードバックを作成することが、DevOpsを支える主要な原則です。 そうすることで、カスタマーが本当に望むものを確実に提供できるようになるだけでなく、開発の負荷を軽減しデプロイメント時の不安を軽減し、運用（Operations）と開発（Development）の関係を改善し、生産性を高めることができます。

Functional Testing

機能性を検証するためのend-to-endシステムのテスト。 実行可能な仕様では、アプリケーションに対して仕様を実行することによりFunctional Testingが実行されます。

Governance

ITにおいて、ガバナンスとは、組織の実施した技術投資が期待通りの働きをし、新しいリスクをもたらさないことを評価および保証するプロセスを指します。 正式なガバナンスプロセスは、企業がITアクティビティとビジネス目標とが一致することを保証すると同時に、すべてがOWASP、PCI 3.2、CWE / SANSなどの共通標準に準拠することも保証します。

Hybrid Cloud

オンプレミス、プライベートクラウド、サードパーティのクラウドサービスを組み合わせて使用するクラウドコンピューティング環境。 企業がソフトウェアデリバリプロセスを拡大すると、使用ニーズとコストが変化します。hybrid cloudソリューションを使用することで、フレキシビリティが上がり、デプロイメントのオプションが増えます。

Infrastructure as a Service (IaaS)

クラウドホスト型の仮想マシン。通常は「その都度払い」で請求されます。 ユーザーはマシンを完全にコントロールできますが、必要なミドルウェアとアプリケーションをすべてインストールしてコンフィグレーションする必要があります。

Infrastructure as Code

マシン、ネットワークデバイス、オペレーティングシステム、ミドルウェアなどを完全に自動化可能な形式で指定するシステムコンフィグレーション マネージメントテクニック。 仕様、または「Blueprint」は、プロビジョニングツールによって実行され、バージョンコントロールされ、一般にアプリケーションコード開発に使用されるのと同じプラクティスに従うコードと見なされます。

Jenkins

Javaで書かれたオープンソースの自動化サーバーがJenkinsです。継続的インテグレーションの事実上の基準となっています。Jenkinsを利用して、デベロッパーは一日に何度も共有されたリポジトリに自分たちのコードを統合することができます。組織がソフトウェアデリバリプロセスの規模を拡大しようとすると、Jenkinsにはスクリプトの作成やワークフローの維持が必要になり、継続的デリバリに拡張する必要があることがよくわかります。 継続的デリバリでは、継続的インテグレーションのツールだけでなく、end-to-endのリリースオーケストレーション、テストの自動化、セキュリティ、ITサービスマネージメントなどのツールも活用します。

Kubernetes

コンテナベースのアプリケーションには、他のエンタープライズアプリケーションと同じリリースプロセスが必要です。 実際、開発環境、テスト環境、ステージング環境、および実稼働環境全体で、アプリケーションが進化し、より多くのマイクロサービスとより多くのコンテナに依存するにつれて、事態はさらに複雑になる可能性があります。 Kubernetesは、複数のホストでコンテナ化されたアプリケーションを管理するためのオープンソースシステムであり、アプリケーションのデプロイメント、メンテナンス、およびスケーリングのための基本的なメカニズムを提供します。

Lean

「無駄のない（lean:リーン）製造」または「無駄のない（lean:リーン）生産」とは、価値の維持に焦点を当てることにより、生産プロセスの無駄を削減することを目的としたアプローチまたは手法です。トヨタが自動車製造で開発したプラクティスから大部分が派生し、アジャイル手法の一部としてlean概念がソフトウェア開発に適用されました。 価値があり、無駄なプロセスステップを視覚的に特定しようとするValue Stream Map（VSM）は、重要なleanツールです。

Microservices

言語に依存しないAPIを使用して相互にコミュニケートする小さな独立したプロセスで複雑なアプリケーションを構成するソフトウェアアーキテクチャ設計パターン。 これらのサービスは小さく、高度に分離されており、小さなタスクの実行に重点を置いています。

Non-functional Requirements (NFRs)

使いやすさ、設計の明確さ、レイテンシー、速度、多数のユーザーを処理する能力などのシステム品質の仕様はどれだけ簡単にまたは効果的に使用できるかを意味します。これらの特性は、継続的デリバリのフィードバックループを使用して対処および改善することもできます。

NoOps

アプリケーションが実行されるシステムの管理が外部の当事者（PaaSベンダーなど）によって完全に処理されるか、完全に自動化された組織のタイプ。 NoOps組織は、社内の運用能力またはスタッフをほとんど、もしくは、まったく必要としないようにするということを目標としています。

Open Source

誰でも変更できるソースコードを持つプログラムまたはアプリケーションを指します。 AngularJSやReactなどのさまざまなオープンソースフレームワーク、GradleやJenkinsなどのオープンソースツール、JHipsterなどのオープンソースライブラリがあり、特定のソフトウェア開発およびデプロイメントプロセスを改善するために使用できます。 複雑なエンタープライズ環境では、DevOpsプラットフォームはオープンソースツールを統合し、それらをデリバリパイプラインに合理化できます。

Orchestration Pipeline

継続的デリバリパイプラインを構成するさまざまな自動化タスクを適切なタイミングで呼び出すことを可能にするツールまたは製品。 また、通常、これらの各タスクの状態とアウトプットを記録し、パイプラインを通る機能のフローを視覚化します。

Platform as a Service (PaaS)

クラウドホスト型のアプリケーションランタイムのことを指します。通常は「その都度払い」で課金されます。 顧客はアプリケーションコードと限定されたコンフィグレーションセッティングを提供しますが、提供されたランタイムの一部はミドルウェア、データベースなどになります。

Product Owner

開発チームが取り組むべき優れた機能やその他の作業のリストの設定、優先順位付け、メンテナンスを担当する人またはその役割。Product Ownerは、アジャイルなソフトウェア開発においては一般的で、ビジネスもしくは顧客組織を意味します。Product Ownerは従来のソフトウェア開発プロセスの対応者よりも、開発プロセスでより積極的かつ日々の役割を果たす必要があります。

Provisioning

ユーザーのための新しいシステムを準備するプロセスのこと。継続的なデリバリのシナリオにおいて、この働きは、一般的には開発チームかテストチームが行うものとされています。そのシステムは一般に仮想化され、オンデマンドでインスタンス化されます。 オペレーティングシステム、ミドルウェアなどをインストールするためのマシンのコンフィグレーションは、自動化されたシステムコンフィグレーションマネージメントツールによって処理されます。このツールは、目的のコンフィグレーションが維持されていることも確認します。

Quality

継続的なデリバリパイプラインを使用すると、より迅速に行動して配信できますが、それでもユーザーに高品質の製品を配信する必要があります。品質に対するそういった期待を最初からソフトウェア開発プロセスに組み入れることもできます。１つのコードのラインが書かれる前にテストを設計します。自分のＣＤパイプラインの中に入れこむことのできるテストアーキテクチャーを作成します。開発の適切なタイミングで適切なテストを適用し、ユニットテストからパフォーマンステストまでをカバーする自己調整システムをビルドします。 そうすれば、ソフトウェアの品質について必要なリアルタイムの情報が常に得られます。

Regression Testing

end-to-endシステムをテストして、アプリケーションの変更が既存の機能に悪影響を与えなかったことを確認すること。

Release Coordination

コードのチェックインから実稼働までの新しい機能または機能セットを取得するために必要なすべてのアクションの設定と実行。継続的なデリバリ環境において、これは、大部分または完全に自動化され、パイプラインによって実行されます。

Release Management

開発段階から実際のソフトウェアリリースそのものまでのソフトウェアリリースを管理するプロセス。

Release Orchestration

企業がリリースパイプラインを効率的に管理および最適化できるように支援すること。これは、継続的デリバリーとDevOpsのメリットを生かしたい企業には必要なものです。エンタープライズ向けのRelease orchestrationソリューションは、リリースステータスの重要なリアルタイムの可視性を提供し、詳細なレポートと分析を通じて、最適な意思決定に必要な機密情報を提供します。Release orchestrationツールは、リリースプロセスをコントロールし、コンプライアンス要件を施工し、監査可能な方法でリリース計画を簡単に変更できるようにします。 また、ビジネスと技術の両方の複数のチーム間で調整する必要がある手動タスクと自動タスクの両方を管理します。

Shifting Left

デリバリースピードの向上に伴い、さまざまなアプリケーション、チーム、環境にわたるセキュリティリスクとコンプライアンスの問題が急増しています。Shifting leftとは、リスク評価、セキュリティテスト、およびコンプライアンス評価プロセスをデリバリーパイプラインの早い段階で統合することを指します。そうすることで、潜在的なリリースの遅延または障害、本番環境を脅かすセキュリティ脆弱性、および高額な罰金を受けることになるITガバナンス違反に、より安い費用で簡単に対処できます。

Software Chain of Custody

Software Chain of Custodyは自分のソフトウェアデリバリパイプラインですべてのことが起きたというエビデンスを示してくれます。法的事件に関係する証拠のchain of custodyがその証拠が適切に処理されたことを証明するように、software chain of custodyは、何が起こったのか、いつ起きたのか、どこで起きたのか、誰が起きたのかを証明してくれます。

この情報がないと、ソフトウェアを大規模に開発および提供する際に、コンプライアンスとセキュリティの要件を満たすことは不可能です。

Test-Driven Development (TDD)

コードのビヘイビアを検証する小さなテストをコード自体の前で書く開発プラクティス。 そのテストは最初は失敗します。開発者の目的はコードを追加してテストを成功させることです。

Toolchain

ソースコード管理や継続的なインテグレーションから、環境のプロビジョニングやアプリケーションのデプロイメントまで、企業のDevOpsのプラクティスで特定のプロセスを実行するためのツールがたくさんあります。 DevOps toolchainとは、アプリケーションのデリバリ、開発、および管理や連携して機能するツールのセットを指します。

Unit Testing

個々のコードのビヘイビアを検証するためのコードレベル（つまり、実行するために完全にインストールされたend-to-end システムを必要としない）テスト。 テスト駆動開発では、unit testを広範囲に使用して、意図したビヘイビアを表示および検証します。

Value Stream Mapping

無駄のない製造およびエンジニアリングのアプローチにおいて、頻繁に使用されるプロセスの視覚化と改善の手法。 Value Stream Mapは、重要なプロセスのステップと、プロセスから徐々に排除できる「無駄」を見分けるために使用されます。

Virtualization

ユーザーとアプリケーションが物理マシンを使用せず、実行中のシステムをシミュレートするシステムマネージメントアプローチ。実行中のシミュレーションされたシステムは、実際では「本物の」ハードウェア上で走っています。 このような「仮想マシン」は、ほんの数秒で自動的に作成、起動、停止、クローン作成、および破棄できるため、非常に柔軟な操作が可能になります。

Waterfall

「要件の収集」から「開発」を経て「リリース」までにおける、プロジェクトへの段階的アプローチに基づいたソフトウェア開発方法論。遅延としてプロジェクトに時間的なプレッシャーをかける場合、プロセスの後半のフェーズ（通常はテストとQAに関連している）は押し込められる傾向にあります。

White Box Testing

実行中の（内部）ビヘイビアと状態を調べることにより、システムの内部が正しく機能していることを検証することに基づいたテストまたは品質保証の実践。

YAML

YAML、これは「YAML Ain’t Markup Language（YAMLはマークアップ言語ではない）」の頭文字です。これは人間が読めるデータのシリアル化された言語です。YAMLファイルは仕様のデプロイメントとリリースのプロセスを自動化するもので、ソフトウェアデリバリの中で使われます。YAMLファイルを使って、自分の既存のアプリケーションやパイプラインからのコンフィグレーションを利用することができます。それは開発環境で使用するおなじみの構成体を表します。

Zero Tolerance

同様に、実稼働環境での障害に対するzero tolerance（わずかな不具合も見逃さず、不良品を徹底的に排除すること）。顧客は障害に対する許容度がゼロ（zero tolerance）です。 デプロイメントの失敗、または顧客向けソフトウェアへのサービスの中断はとても影響が大きく、特に規制の厳しい業界の組織に壊滅的な影響を与える可能性があります。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。