関連
IT 運用
システム運用
運用プロセス
運用設計
en : reliability
関連
ソフトウェアの信頼性
基準点からのサービスの連続遂行可能時間 (故障に至るまでの時間) を表す尺度 (1)
平均故障寿命 (mean time to failure : MTTF) はひとつの尺度
関連 : ソフトウェア保守
i コンピテンシ ディクショナリ より
以下のようなことを行う
機能要件と非機能要件の定義
インターフェイス要件の定義
サブシステム間や他システムとのインターフェイスの要件
en : System/Software Requirements Definition process
同義 : システム及び/又はソフトウェア要件 (要求事項) 定義プロセス (JIS X 0160 での訳)
共通フレーム 2013 においては、システム要件定義プロセスやソフトウェア要件定義プロセスがこのプロセスに該当するぽい
JIS X 0160:2021 より
en : Implementation process
共通フレーム 2013 のソフトウェア構築プロセスは、このプロセスを特化したものっぽい
JIS X 0160:2021 より
ソフトウェアライフサイクルプロセスにおけるテクニカルプロセスのひとつ
指定されたシステム要素を実現することを目的とする
『SEC BOOKS 共通フレーム 2013』 より
運用プロセスの中のアクティビティ
タスク
実施計画の作成 (運用プロセスのアクティビティ及びタスクを実施するための計画)
運用のための資産の引き継ぎ
→ /yunoha-pub/JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
対応国際規格 : ISO/IEC/IEEE 29148:2018 (IDT)
関連
JIS X 0166
en : Architecture Definition process
ソフトウェアライフサイクルプロセスにおけるテクニカルプロセスのひとつ
JIS X 0160:2021 より
システムアーキテクチャの候補およびその代替案を作成し、利害関係者の関心事を捉え、システム要件を満たす 1 つ以上の代替案を選定し、一貫した一連の複数のビューの中でアーキテクチャを表現することを目的とする
共通フレーム 2013 で定義されているプロセス
ISO/IEC 15288 の要求事項分析プロセスを特化したもの
JIS X 0160:2021 におけるシステム/ソフトウェア要件定義プロセスに該当するはず
定義された利害関係者要件を、システムの設計を導く、システムの技術的要件の集合に変換する
成果物として、システム要件を明記する
en : development strategy
ISO/IEC/IEEE 24748-1:2018 より
システムおよびソフトウェアのプロジェクトに適用できる 3 つの開発戦略
Once-Through : いわゆるウォーターフォール
Incremental : 最初に、ユーザーニーズ (user needs) の決定とシステム要件 (system requirements) の定義をして、それから開発の残りの部分を複数ビルドの連続で行う
i コンピテンシ ディクショナリ より
システム要件およびシステム方式に準じたテスト
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
システム化構想を実現するために、運用や効果等の実現性を考慮したシステム化計画とプロジェクト計画を具体化し、利害関係者の合意を得ることが目的
アクティビティとしては、準備、立案、承認、がある
『SEC BOOKS 共通フレーム 2013』 より
共通フレーム 2013 のサービスマネジメントプロセスは JIS Q 20000 を引用している
このプロセスは、JIS Q 20000 に準拠したサービスマネジメントシステムを構築している組織が、顧客に IT サービスを提供する運用において、活動と資源を指揮、管理することを目的とする
『SEC BOOKS 共通フレーム 2013』 より
システム、ソフトウェア製品、又はサービスの開発を目的とする
要件を、顧客のニーズにあったシステムへと変換する
システムの新規開発や保守に伴う開発、旧システムからの移行に伴う開発で用いられる
以下のプロセスがある
『SEC BOOKS 共通フレーム 2013』 より
意図された環境で、システムおよびソフトウェア製品を運用し、顧客への支援を提供することが目的
成果としては以下
運用の戦略が定義されている
意図された環境下での正しい運用の条件が識別され、評価されている
『SEC BOOKS 共通フレーム 2013』 より
運用しているシステムを定期的に評価するタスク、及びそのタスクのみからなるアクティビティのこと
評価項目の例
要件の実現度、特定の利用目的の実現度
応答時間、処理時間、資源の利用状況
参考
SEC BOOKS 共通フレーム 2013
共通フレーム 2013 解説
https://www.ipa.go.jp/sec/publish/tn12-006.html#dl から体系をダウンロードできる
『SEC BOOKS 共通フレーム 2013』 より
略 : IPA SEC
独立行政法人情報処理推進機構 (IPA) 内に設置されていた組織
2013 年より IPA ソフトウェア高信頼化センター
2018 年には、他部署も含めた統合により IPA 社会基盤センターになったぽい?
『SEC BOOKS 共通フレーム 2013』 (2014 年発行の電子版) の奥付を見ると 「社会基盤センター」 が監修していることになっているから、2014 年には社会基盤センターがあった?
共通フレーム 2013 においては、JIS X 0160:2021 の利害関係者ニーズ及び利害関係者要件定義プロセスを単に要件定義プロセスとしている
いわゆる業務要件定義を行うプロセス
関連
利害関係者要件
『SEC BOOKS 共通フレーム 2013』 より
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
経営上のニーズの実現や課題解決のために、経営環境を踏まえて、新たな業務の全体像とそれぞ実現するためのシステム化構想及び推進体制を立案する
アクティビティとしては、準備、立案、承認、がある
ISO/IEC 29148 の A.2.5 「Concepts for the proposed system」 を参考にすると良い
『SEC BOOKS 共通フレーム 2013』 より
共通フレーム 2013 におけるテクニカルプロセスのひとつ
目標達成に係るシステムの要件の集合と、システム化の方針、システム実現のための実施計画を得ることが目的
要件定義プロセスや開発プロセスに先だって実施する想定
事業の見直しを伴わないシステムに関しては、本プロセスを省略しても良い
識別された利害関係者のニーズ、欲求、要望、期待及び識別された制約条件を記述するもの
文章又は形式的表現によるモデルを使用して表現する
システムの目的及び振る舞いに焦点を当てる
関連
利害関係者ニーズ及び利害関係者要件定義プロセス
#nobuoka/購入した書籍
2022-12
天才読書
2022-11
コンテナ物語
ISO/IEC TR 15271 (ISO/IEC 12207 の手引き) に記載されている開発モデルのひとつ
顧客の要求から始まり、計画、モデリング、構築、デプロイと順に進んでいく
参考文献
SEC BOOKS 共通フレーム 2013
実践ソフトウェアエンジニアリング 第 9 版
nobuoka/読んだ本
12 月
ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ
みんなのコンピュータサイエンス
世界標準のデータ戦略完全ガイド データセンスを磨く事例から、データの種類と仕組み、戦略策定のステップまで
en : architecture
JIS X 0160:2021 の定義 : システムが存在する環境の中での、システムの基本的な概念又は性質であって、その構成要素、相互関係、並びに設計及び発展を導く原則として具体化されたもの
SLCP-JCF2013 の定義 : システムのある境界 (例えば、入出力系、プロセッサ、ネットワークなど) に対して、それらの外側から見た場合の概念的あるいは論理的な属性又は構造。 「方式」 と訳される場合が多い。 (from SEC BOOKS 共通フレーム 2013)
アーキテクチャのこと
『SEC BOOKS 共通フレーム 2013』 の用語集に、アーキテクチャについて 『「方式」 と訳される場合が多い』 と書かれている
システム開発における要求と要件の違いについて、標準的な定義は無い模様
英語の requirement の訳として、要求も要件も使われるっぽい
『ユーザのための要件定義ガイド 第 2 版』 では、「要求を文書化、仕様化し、ステークホルダーと合意したもの」 を要件としている
『経営者が参画する要求品質の確保 ~超上流から攻める IT 化の勘どころ~ 第 2 版』 における使い分け
以下のような使い分けを考えている様子
『SEC BOOKS 共通フレーム 2013』 より
要求と要件は、いずれも requirement の訳語
国際規格での定義の例 : 製品またはプロセスの運用/機能/設計上の特性を識別する文で、曖昧性がなく、テスト可能で、測定可能で、(顧客または内部の品質保証ガイドラインに) 受け入れられるために必要であるもの
事業目的や業務目的に照らして 「本当に必要か」 が十分検討され、要求が満たされたことの基準や手段がはっきりしており、明文化されているもの
『SEC BOOKS 共通フレーム 2013』 より
業務運用を定期的に評価するタスク、及びそのタスクのみからなるアクティビティのこと
評価項目の例
要件の実現度、特定の利用目的の実現度
システム運用移行、業務運用移行時の影響
en : Quality Management process
JIS X 0160:2021 より
ソフトウェアライフサイクルプロセスのひとつ
目的 : 製品、サービス、品質管理プロセスの実施が組織とプロジェクトの品質目標に合致し、顧客満足を達成することを保証する
以下のアクティビティから成る
『SEC BOOKS 共通フレーム 2013』 より
組織に適切な人的資源を提供し、能力を維持向上するための作業を包括的に定めたもの
組織が必要とするスキルやキャリアを定義し、それを向上させるような教育訓練を組織的に、計画的に行う
アプリケーションの品質
ユーザビリティ
サイト全体としての理解しやすさ
オンラインフィードバックやオンラインヘルプに関する機能
インターフェイスや審美性に関する機能
JIS X 25010:2013 より
製品品質についての品質モデル
システム/ソフトウェア製品の品質特徴を 8 つの特性に分類
機能適合性 (functional suitability)
性能効率性 (performance efficiency)
アーキテクチャ設計の一部として具体化すべき一連の特性 (Mary Shaw、David Garlan による)
構造特性 (structural properties)
システムのコンポーネントと、それらのコンポーネント同士のやりとりの方法
余剰機能特性 (extra-functional properties)
アーキテクチャ設計が、性能、キャパシティ、信頼性、セキュリティなどの非機能要求等のシステム特性をどう達成するか
アーキテクチャ特性の一種
部分的なリスト
可用性 (Availability)
継続性 (Continuity)
パフォーマンス (Performance)
非機能要件を定義すること
from はじめての設計をやり抜くための本 第 2 版
信頼性と効率に関しては、具体的な目標値をユーザー企業担当者に提示してもらうことが良い
スループットやレイテンシ、稼働率には具体的な数値を目標に設定
機能性のセキュリティに関してはガイドラインを参考に検討
個人の利用者は応答時間 (実行時間) の短さ、コンピュータセンターの管理者はスループットまたはバンド幅を増やすことに関心
実際のコンピュータシステムでは、応答時間とスループットのいずれかを変えるともう一方にも影響することが多い
『コンピュータの構成と設計 第 5 版』 では主に応答時間に着目
コンピュータの性能を表す完全かつ信頼性のある唯一の尺度は時間
時間の測り方は様々
アーキテクチャスタイルを指して、単に 「REST」 と呼ばれることもある。
HTTP リクエストを送ることでいろいろな web サービスを利用するための仕組み (1)
本当に??
最も重要なのは 「リソース」 の概念 : 鍵となる情報の抽象
Resource Oriented Architecture (ROA)
en : Regression Testing
同義 : リグレッションテスト
System Under Test (SUT) を選択的に再テストして、変更によって意図しない効果が生じていないこと、および SUT が指定された要件に準拠していることを確認すること
場合によっては、変更が行われるたびに回帰テストによって提供される保証と、回帰テストを実行するために必要なリソースとの間でトレードオフがある
関連 : ISO/IEC 9126
6 つの品質特性
機能性 (functionality)
信頼性 (reliability)
使用性 (usability)
https://sre.google/sre-book/table-of-contents/
#SRE #Google #書籍
トピックごとの更新が https://sre.google/resources/book-update/ で
Part 1 : Introduction
1 章 : Introduction
Site Reliability Engineering (SRE) の原則
エンジニアリングに永続的に注力できること
余分な運用作業を開発チームにリダイレクトする (オンコールローテーションに開発チームを統合するなど)
運用負荷が 50 % 以下になったらリダイレクトは終了
効果的なフィードバックメカニズムにもなる
コンピュータアーキテクチャにおける 8 つの主要なアイデア
Moore の法則の設計 : 設計を開始したときではなく終了したときに技術がどこまで進歩しているか?
設計を単純化するための、抽象化 : 層別して設計を行う → 上位レベルは下位レベルの詳細を隠すことでモデルを単純化
一般的な場合を高速化する : 一般的な場合を把握するには注意深い実験と測定が必要
並列処理による性能向上
en : software system
JIS X 0160:2021 の定義 : 利害関係者にとって、ソフトウェアが最も重要であるシステム
一般的に、ソフトウェアシステムは、ハードウェア、ソフトウェア、人員及び手作業で構成される
ソフトウェア開発の成果物
3 つの重要な特性 (1)
記憶階層の信頼性と可用性
Richard Hamming がデータに冗長ビットを持たせる方式を考案
Hamming 距離 (Hamming distance)
1 ビット誤り検出コード (error detection code)
誤りを検出するための冗長ビットとしてパリティコード (parity code) を使用
en : high velocity IT
重要なビジネスを実現するため、デジタルテクノロジーを適用すること
5 つの目標
価値ある投資 : デジタルへの投資がビジネス戦略に大きく貢献
迅速な開発
ソフトウェアの信頼性
from 実践ソフトウェアエンジニアリング 第 9 版
特定の環境、特定の時間内において、コンピュータプログラムが故障することなく運用される確率
故障とは?
ソフトウェアの故障とは、ソフトウェア要件に対する不適合
ソフトウェアの安全性
from 実践ソフトウェアエンジニアリング 第 9 版
全システムの故障につながりかねない潜在的なハザード (危険) を特定し、評価することにフォーカスしたソフトウェア品質保証のアクティビティ
ソフトウェアの故障が、どのようにして事故に繋がりかねない状況になるのかを調べる
故障を、コンピュータベースのシステム全体のコンテキストの中で評価
キーワード : 日本企業、デジタル変革、デジタルトランスフォーメーション
from マッキンゼーが解き明かす生き残るための DX
経営陣の同床異夢
デジタルの重要性は認識しているが、何を対象にどれぐらいの規模でデジタル変革しようとしているか言語化されていない
DX はトップダウンで進めるのが定石
変更承認プロセスにセキュリティとコンプライアンスを組み込む
from: The DevOps ハンドブック 理論・原則・実践のすべて
ある程度の規模の IT 組織のほとんどは、変更管理プロセスを持っている
運用におけるセキュリティリスクを低減する
ITIL における 3 種類の変更
同義: FIDO アライアンス
https://fidoalliance.org/overview/?lang=ja
FIDO アライアンスは、パスワードへの過度の依存を減らすための認証標準という、焦点を絞った使命を持つオープンな業界団体である。 FIDO アライアンスは、認証およびデバイス認証の標準の開発、使用、および準拠を促進する。
パスワードは、置き換えられないまでも、その使用を減らす必要があるというコンセンサスが高まっているにもかかわらず、使われ続けている。 消費者はユーザー・エクスペリエンスを好まず、オンライン・サービス・プロバイダーは独自の専用ソリューションを開発しプロビジョニングするコストと複雑さを望まない。
アーキテクチャ特性の一種
部分的なリスト
アクセシビリティ (Accessibility)
長期保存性 (Archivability)
認証 (Authentication)
https://atmarkit.itmedia.co.jp/ait/spv/2209/22/news013.html
OSS の使用リスク対処として注目を集めている
SBOMとソフトウェアサプライチェーンの話題
DevOps は、開発者と運用者が協力してサービスを改善していくもの
ユーザーからのフィードバックなどを受けて取り組みを繰り返し、改善を継続する
サービスマネジメントの 4 つの側面のひとつ、情報と技術について
サービスマネジメントを支える技術 : ワークフロー・マネジメントシステム、ナレッジベース、インベントリ・システム、通信システムおよび分析ツールなど
検討すべき事項
どのような情報がサービスによって管理されるか
サービスを提供・管理するために、それをサポートするための情報やナレッジとしてどのようなものがあるか
同義 : 非機能要件
様々な定義がある
JUAS の 『非機能要求仕様定義ガイドライン』 など参照
『システムを作らせる技術』 における大分類
可用性
Kubernetes 環境での extended Berkeley Packet Filter (eBPF)
ホスト上のすべてのコンテナは同じカーネルを共有している
eBPF でカーネルの適切なイベントを検知することで、Kubernetes ノードのあらゆる事象の発生を認識できる
可観測性やセキュリティにも役立てられる
ネットワーク可観測性ツール Hubble
コンテナのセキュリティ
米国国立標準技術研究所 (NIST) によるコンテナセキュリティのガイドライン
SP 800-190
NISTIR 8176
リスクのカテゴリ
有用性と保証について。
ITIL においては、いわゆる機能と非機能を以下のように捉えている
機能 → サービスの有用性
非機能 → サービスの保証
以下の 4 項目が主な構成要素
ソフトウェアエンジニアの 3 大キャリアパス
多くの場合、「技術」 「人・組織」 「プロダクト・ビジネス」 の 3 領域
キャリアパスとしては次の 3 つ
1. エンジニアを極める → ソフトウェアエンジニアを極めるキャリアパス
2. エンジニアリングマネジャーを志向する → ソフトウェアエンジニアからエンジニアリングマネジャーを志向するキャリアパス
製品やサービスが合意済みの要件を満たすことに対する確約
「サービスがどのように提供されるか」 であるといえる
「サービスが使用に適しているか」 の判断に使える
一般的に、サービスの可用性やキャパシティ、セキュリティ、継続性を確約する
参考文献
アーキテクチャ特性またはアーキテクチャ特性の組み合わせについて、客観的な整合性評価を行うための何らかの仕組み (1)
アーキテクチャ特性の整合性を客観的に評価するもの
『進化的アーキテクチャ ―― 絶え間ない変化を支える』 では、単に適応度関数と言われていた
評価には、メトリクスやユニットテスト、監視、カオスエンジニアリングなど、様々な仕組みが使われる
分類
ドメインの関心事からアーキテクチャ特性への翻訳の例が 『ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ』 に示されている
合併、買収 → 相互運用性、スケーラビリティ、適応性、拡張性
市場投入までの時間 → アジリティ、テスト容易性、デプロイ容易性
ユーザー満足度 → パフォーマンス、可用性、耐障害性、テスト容易性、デプロイ容易性、アジリティ、セキュリティ
Transport Layer Security (TLS) を利用したアプリケーションやシステムを開発するうえで重要となるセキュリティ上の課題
from 徹底解剖 TLS 1.3
脆弱性の階層
暗号アルゴリズム
攻撃側の技術や性能向上による危殆化がある
en : Perfect Forward Secrecy
略 : PFS
from ゼロトラストネットワーク ―― 境界防御の限界を超えるためのセキュアなシステム設計
秘密鍵が漏洩したとしても、ネゴシエート済みのセッションのセキュリティは侵害されないという暗号化の特性のこと
from 徹底解剖 TLS 1.3
en : Elliptic Curve Diffie-Hellman
略 : ECDH
from ゼロトラストネットワーク ―― 境界防御の限界を超えるためのセキュアなシステム設計
Diffie-Hellman 鍵交換をベースに、鍵の共有に楕円曲線を使用する
楕円曲線暗号法は非常に強力で、効率がよく、現在でも解くのが難しい数学問題に基づく
ソフトウェア品質保証の構成要素
from 実践ソフトウェアエンジニアリング 第 9 版
IEEE や ISO などの規格団体がソフトウェアエンジニアリングに関する規格を発行 → 事前に適用すると決めた規格に対して、作業成果物が準拠しているかどうか
テクニカルレビューは、ソフトウェアエンジニアによるソフトウェアエンジニアのための品質コントロールのアクティビティ
監査は、SQA の人員が行うレビューの一種
en : Non Functional Requirement
略 : NFR
『ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ』 では、非機能要件の代わりにアーキテクチャ特性という言葉が使われている
『ビヨンドソフトウェアアーキテクチャ』 より
アーキテクチャに関する様々な品質やプロダクト特性のこと
キーワード : デジタルトランスフォーメーション
from マッキンゼーが解き明かす生き残るための DX
レガシーシステムや技術的負債が壁になる
クラウド活用を阻むセキュリティ懸念 → ゼロトラスト
ウォーターフォール型開発の弊害
en : zero trust proxy
ゼロトラストネットワークをセキュリティで保護するためのアプリケーションレベルのプロキシサーバー
アイデンティティー認識型プロキシ (IAP) もゼロトラストプロキシの一種?
from ゼロトラストネットワーク ―― 境界防御の限界を超えるためのセキュアなシステム設計
認証、認可、暗号化を処理するためのインフラストラクチャとして導入される
ビジネスコンセプト : 構想立案時やシステム化企画時に検討され、要件定義開始時に提示されていることが多い
ビジネスコンセプト確認ドキュメント
ステークホルダー (利害関係者)
ステークホルダー関連図
ステークホルダー一覧
それぞれのレベルの範囲が、コンピュータシステム全体から、集積回路に存在する小さな機能ユニットにおよぶ
それぞれの範囲を表現するのに使う用語
システムレベル・アーキテクチャ (巨視的アーキテクチャ)
プロセッサ、メモリ、I/O デバイスを含む完全なコンピュータ
典型的なシステム・アーキテクチャは、コンポーネントとバスとの相互接続を記述
アプリケーションプログラムと外部のハードウェア機器との間にインターフェイスを提供するソフトウェア
デバイスドライバの機能は、次のコードの共同作業で実装される
バスを介して通信を行うコード
デバイスの詳細を扱うコード、
アプリケーションとのやりとりを行うコード
ユーザーインターフェイス設計もインターフェイス設計の一種?
Web API の設計もインターフェイス設計の一種のはず
See : Web API の設計
システムと連携するソフトウェアや人間のやりとりを説明するもの
インターフェイスは情報の流れと具体的な振る舞いを定義する
en : user interaction design
製品とそのユーザーの間のインターフェイスに焦点を当てる
en : coupling
関連 : 結合度
ソフトウェアを構成するモジュール同士が、どれぐらい互いに依存しているかを示す指標
モジュール間のインターフェイスの複雑さに応じて変化
参考文献
from はじめての設計をやり抜くための本 第 2 版
ユースケース記述や概念モデルといった要件定義の成果物をもとに、オブジェクト指向分析をするための手法
ユースケース記述や概念モデルからクラスを抽出できる
ロバストネス分析では、クラスを 3 種類に分類 (MVC モデルと似ている)
バウンダリ : システムと外部とのインターフェイス (外部仕様に相当)
from はじめての設計をやり抜くための本 第 2 版
外部仕様とは、システムがユーザーや外部システムに対して提供する機能やインターフェイスのこと
システムの設計
『経営者が参画する要求品質の確保 ~超上流から攻める IT 化の勘どころ~ 第 2 版』 より
超上流工程の後工程に位置づけられる
画面や帳票などのインターフェイスを決める外部設計と、内部ロジックや物理データ構造を決める内部設計に分かれる
情報システム部門は、この設計書により開発工程に進むことができるかの判断を実施
i コンピテンシ ディクショナリ より
以下のようなことを行う
ソフトウェアコンポーネントの方式設計
ソフトウェア要件定義で定義されたプロセスをコンポーネントに分割
全てのソフトウェア要件が分割されたコンポーネントのいずれかに割り当てられていることを確認
運用および保守のしやすさについての非機能要求のカテゴリ
保守性と運用性を合わせたもの、という理解でよいのかな
最近だと持続可能性というような表現もあったりするっぽいが、それに近い?
参考文献
システムを作らせる技術
IT バリューストリームのサブセット
開始 : バリューストリームに属するエンジニア (QA なども含む) が変更を VCS にチェックインしたとき
終了 : その変更が本番環境での稼働に成功し、顧客に価値を提供して役に立つフィードバックや遠隔測定データを生成したときに終わる
第 1 フェーズである設計と開発はリーン製品開発とよく似ている
可変性と不確実性が高く、高度な創造性と再現できないような作業を必要とすることが多い
『The DevOps ハンドブック 理論・原則・実践のすべて』 より
バリューストリームの全てのステージで、右から左にコンスタントにフィードバックを返せるようにすること
複雑なシステム (複雑系?) の特徴
システム全体を把握して全ての部品がどのように関連しているか誰にも理解できない
同じことを 2 度しても、必ずしも同じ結果にはならない
『The DevOps ハンドブック 理論・原則・実践のすべて』 より
顧客にすばやく価値を届けるために、開発から運用への作業の流れを早くスムースにする
作業を可視化し、バッチサイズを縮小し、作業のインターバルを短縮し、品質を組み込んで下流に不良品が流れないようにする
やるべきこと
作業の可視化
https://dora.dev/
ソフトウェアのデプロイと運用パフォーマンスを促進する機能を理解することを目的としたプログラム
DORA は、チームがこれらの機能を適用できるように支援し、組織のパフォーマンスの向上につなげる
委託者から所有分離された資産を、受託者が管理・運用して、その利益を受益者に還元する仕組み
中世の英国に起源がある
登場人物
委託者 : もともとの資産の所有者
受託者 : トラストされた財産の所有者
DevOps の手法は 「安全で耐障害性が高く急速に進化できるスケーラブルな分散型システムを構築するためにはどうしたらよいのか」 という難題を抱えた、少数の組織から生まれてきた手法である
(『Lean と DevOps の科学 Accelerate』 より)
DevOps は、クラウドや運用監視、データ分析などの技術や手法と、さまざまなオペレーションの自動化、これらを実践する組織、そして絶えず改善をし続けるという組織文化から構成される
https://tatsu-zine.com/books/continuous-delivery
著 : Jez Humble、David Farley
訳 : 和智右桂、髙木正弘
序文
サイクルタイムはどんなプロジェクトにとっても欠くことができない指標
投資家から資金を募り、株式や債券などに投資・運用する商品
サービスマネジメントに対するシステム管理者 (systems administrator or sysadmin) アプローチ
既存のソフトウェアコンポーネントを組み立て、それらが協働するようデプロイしてサービスとして展開
システムの複雑さやトラフィック量の増加に伴い、システム管理者チームは成長して対応していく
システム管理者の役割に求められるスキルセットは開発者のそれとは著しく異なる
開発者とシステム管理者は 「開発 (development)」 と 「運用 (operations or ops)」 に分けられる
オンコールシフトの量と質
量 : オンコール業務に費やした時間の割合で計算
最低でも 50 % はエンジニアリングに充てて、25 % 以下をオンコールに、残り (25 % 程度?) を通常の運用に
常に 2 人のオンコールエンジニアがいるとすると、単一サイトで最低 8 人の SRE エンジニアが必要
デュアルサイトだと、各 6 人ずつが妥当
IT システムの運用
運用自動化の仕組みのこと
リソースの柔軟性とアプリケーションの再利用性を管理する技術
クラウドのリソースの抽象化
背景
ユーザーの要求やサービスの仕様が常に変化する環境においてはアプリケーションのポータビリティが必要
プライベートクラウドとかパブリッククラウドといった場所に依存しないように
from リーンソフトウェア開発と組織改革
複雑性 : ソフトウェアは人が生み出す構造物の中でも複雑
実際に使われるよりも多くの機能が実装される。 ポリシー的に、スコープを縮める決定がなされづらい
顧客はプロセスの自動化を望むが、自動化よりも単純化がまずは重要
→ とにかく単純であることを重視
i コンピテンシ ディクショナリ より
以下のようなことを行う
システム運用設計
IT サービス設計
Web サイト運用設計
https://elaws.e-gov.go.jp/document?lawid=413AC0000000088
この法律は、少子高齢化の進展、高齢期の生活の多様化等の社会経済情勢の変化にかんがみ、個人又は事業主が拠出した資金を個人が自己の責任において運用の指図を行い、高齢期においてその結果に基づいた給付を受けることができるようにするため、確定拠出年金について必要な事項を定め、国民の高齢期における所得の確保に係る自主的な努力を支援し、もって公的年金の給付
『The DevOps ハンドブック 理論・原則・実践のすべて』 より
個人がコンスタントに知識を生み出し、チームや組織の知識に転化していくこと
Westrum 博士による 3 種の組織文化のモデルでいうところの、発生的な文化が重要
例えば、非難なしのポストモーテム (事後検証)
日常的な改善
原著 : Software Engineering: A Practitioner's Approach (9th edition)
著 : Roger S. Pressman、Bruce R. Maxim
訳 : SEPA 翻訳プロジェクト
関連ページ : https://github.com/ohmsha/sepa9th_book
感想
en : modularity
関心事の分離の最も一般的な現れ
モジュール型システムの設計基準に情報隠蔽を用いると、テストや保守で劇的な効果がある
モジュールは 「互いに相手から何を隠すのか」 という観点で特徴づけられる
優れたモジュール性を維持することは、暗黙的なアーキテクチャ特性
en : requirements engineering
同義 : 要求工学
JIS X 0166:2021 より
多分野の協働を必要とする工学で、取得者の領域と供給者の領域とを仲介し、対象とするシステム、ソフトウェア又はサービスが満たすようにする要件を確立し、保守するための工学
要求に関するプロセスとしては以下がある
→ 保守
同義? : イテレーションプランニング、イテレーションの計画
関連 : リリース計画とイテレーション計画の違い
『アジャイルな見積りと計画づくり 〜価値あるソフトウェアを育てる概念と技法〜』 より
イテレーションの開始時に行う計画づくり
直近のイテレーションの内容に応じて、プロダクトオーナーが新しいイテレーションで達成すべき優先度の高い作業を決定
『ソフトウェアエンジニアリング基礎知識体系-SWEBOK V3.0-』 より
ソフトウェア保守の目的は、既成のソフトウェアを、それがもつ完全性を維持しながら是正すること
保守のカテゴリ
是正のための保守 : 発見された問題を是正
適応のための保守 : 引渡し後に、変更された、または変更しようとする環境において、ソフトウェアを使い続けられるようにする
#チームトポロジーの基本的なチーム種別
システムの中で、スペシャリストの知識が必要となる部分を開発、保守する責任を持つ
ほとんどのチームメンバーが、その分野のスペシャリストでなければ理解や変更が難しいようなサブシステムを担当
目的 : 複雑なサブシステムを利用するストリームアラインドチームの認知負荷を軽減すること