Systems Architect Examination key terms

システムの機能そのものではなく、性能、可用性、セキュリティ、保守性、拡張性など、品質や制約に関する要求事項を指す。機能要件と対比され、設計方針や方式選定の根拠となる。

応答時間、スループット、同時接続数など、システムが満たすべき処理能力の目標値。測定可能な指標として定義され、容量設計や負荷試験の判定基準に用いられる。

故障や障害が発生してもサービスを継続できるよう、冗長化、フェイルオーバ、監視などの仕組みを方式に組み込む設計手法。目標とする稼働率や許容停止時間から逆算して構成を決める。

同じ役割を担う機器や処理系を複数用意し、一部が故障しても全体の機能を維持できるようにする構成。待機系を常時同期させる方式と、切替時に起動する方式がある。

稼働中の系に障害が発生した際、待機系へ処理を自動的に引き継ぐ仕組み。切替時間、データの整合性、業務への影響を設計時に明確にする必要がある。

目標復旧時間。災害や重大障害の発生から、業務を再開できる状態に復旧するまでの許容時間を表す。バックアップ方式や待機系の配置を決める前提となる指標。

目標復旧時点。障害発生時に、どの時点までのデータを復元できていれば許容できるかを示す指標。バックアップの頻度や複製方式の設計に直結する。

災害やシステム停止時にも重要業務を継続または早期再開するための方針、体制、手順を定めた計画。システムの復旧目標と業務側の優先順位を整合させる。

将来の利用量や負荷の伸びを見積もり、CPU、記憶域、回線などの資源をあらかじめ確保する計画活動。監視データと成長率を用いて余裕率を含めて算定する。

利用者やデータ量の増加に応じて、性能を保ちながら処理能力を拡張できる性質。機器を増やす水平拡張と、性能を高める垂直拡張に大別される。

複数のサーバや処理系に要求を振り分け、特定の装置への集中を避ける方式。振分けアルゴリズム、セッションの保持方法、障害時の除外動作を設計で決める。

複数の計算機を連携させ、一台のシステムのように見せる構成。可用性を高めるHAクラスタと、処理能力を高める負荷分散クラスタがある。

想定される利用量や同時実行数を模擬してシステムに与え、応答時間や資源使用率、限界点を測定する試験。性能要件の達成を確認するために実施する。

システムを構成する要素、その責務、要素間の関係や配置を定める設計活動。非機能要件を満たすための全体構造と、方式選定の根拠を示す。

構成要素間の依存を小さくし、一方の変更が他方に波及しにくい構造。インタフェースを明確に定め、内部実装を隠蔽することで保守性と拡張性が高まる。

システムやコンポーネント間で受け渡すデータの形式、項目、エラー時の振る舞いを定める設計。呼出し側と提供側の前提を揃え、結合のしやすさを確保する。

設計書や方式案を第三者が検証し、要求との整合、抜け漏れ、リスクを指摘する活動。実施時期と観点を定め、指摘の追跡管理まで行うことが重要である。

要求から設計、実装、試験までの対応関係を追跡できること。変更の影響範囲を特定し、要求の未実装や過剰実装を防ぐために確保する。

想定される脅威や障害の発生可能性と影響度を見積もり、優先的に対処すべきリスクを特定する活動。対策の要否と残留リスクの受容判断に用いる。

対象システムの構成やデータの流れを整理し、想定される攻撃者と攻撃経路を洗い出す手法。設計段階で対策を組み込むための根拠となる。

境界、サーバ、アプリケーション、データなど複数の階層に防御策を配置し、一つの対策が破られても被害を局限できる考え方。単一の対策に依存しない構成を目指す。

利用者やプロセスに、業務の遂行に必要な最小限の権限だけを与える考え方。権限の肥大化を防ぎ、侵害時の影響範囲を小さくする。

組織が情報資産を守るための基本方針、規範、手順を体系化した文書。技術的な対策の選定や運用ルールの根拠となり、定期的な見直しを要する。

データを別の媒体や場所に複製して保持する方法。フル、差分、増分の組合せや保存期間、復元手順を、目標復旧時点と復旧時間に合わせて決める。

保存したバックアップから実際にデータを復元し、手順の妥当性と所要時間を確認する試験。取得だけ行い復元を検証しない状態を避けるために定期的に実施する。

システムが必要なときに利用できる度合い。稼働時間の割合で表されることが多く、計画停止の扱いを含めて目標値を定義する必要がある。

サービス提供者と利用者の間で合意するサービス水準の取決め。稼働率、応答時間、障害時の連絡や復旧目標などを数値で定め、達成状況を測定する。

サービスの中断や品質低下をできるだけ早く復旧させることを目的とする活動。原因追究より復旧を優先し、恒久的な対策は問題管理へ引き継ぐ。

インシデントの背後にある根本原因を特定し、再発を防ぐための活動。既知の誤りとして記録し、変更管理と連携して恒久対策を実施する。

システムや構成の変更について、影響範囲、リスク、実施手順を評価し、承認と記録を行う活動。変更に伴う障害を防ぎ、構成情報との整合を保つ。

システムを構成する機器、ソフトウェア、設定などの項目とその関係を識別し、記録して最新の状態に保つ活動。変更や障害対応の判断材料となる。

利用者からの問合せや障害報告の窓口となり、受付、記録、一次対応、関係者への引継ぎを行う機能。対応履歴は改善や再発防止の分析に活用する。

誰がいつ何をしたかを事後に検証できるよう記録した履歴。操作の追跡、不正の検知、説明責任の確保に用い、改ざん防止と保存期間の設計が必要である。

認証は利用者が本人であることを確認する手続き、認可は確認された主体に許可された操作を判断する仕組み。両者を分けて設計し、権限を適切に管理する。

ソフトウェア同士が機能やデータをやり取りするための呼出し規約。入出力の形式、認証方法、エラー応答を定め、利用側の実装を容易にする。

利用者や発注者の立場で、要求どおりの機能と品質が得られているかを確認する試験。合否判定の基準を事前に合意し、結果を検収に結び付ける。

稼働後の監視、ジョブ運用、障害対応、変更手順などをあらかじめ定める設計。運用側の負荷と誤操作の可能性を考慮し、自動化の範囲も決める。

どの指標をどの間隔で収集し、どの条件で警報を出すかを定める設計。検知の遅れと誤報の多さのバランスを考慮し、通知先と初動手順も合わせて決める。

記述式・論述式の解答で、結論、理由、具体例、留意点の順に筋道立てて示す組み立て方。設問の問いに直接答え、字数配分を意識して記述する。

問題文が何を問い、どの立場や条件で答えることを求めているかを整理する作業。問いの対象、制約、解答の粒度を確認してから記述を始める。

記述した主張に対して、要求事項、前提条件、技術的な理由などを対応付けて示すこと。結論だけを述べず、なぜその方式を選ぶのかを読み手が追えるようにする。

方式の選択により得られる利点と、失う性質や増える負担を対比して述べること。性能とコスト、可用性と複雑さなど、相反する要素の比較で判断の妥当性を示す。