7.2. MTA のアセスメント質問集
Migration Toolkit for Applications (MTA) は、デフォルト または カスタム のアセスメント質問集を使用して、アプリケーションのコンテナー化に伴うリスクを評価します。
アセスメントレポートは、移行に関連するアプリケーションとリスクに関する情報を提供します。このレポートは、評価用に提出されたアプリケーションの優先度、ビジネスの重要性、依存関係に基づいた導入計画も生成します。
7.2.1. デフォルトのアセスメント質問集
Migration Toolkit for Applications (MTA) のデフォルトの質問集は、Legacy Pathfinder です。Pathfinder は質問集ベースのツールです。エンタープライズ Kubernetes プラットフォーム上のコンテナーにおけるアプリケーションのモダナイゼーションの適合性を評価するために使用できます。
デフォルトの質問集やレビュープロセスとのやり取りの結果、アプリケーションの情報が、アセスメントレポートの収集を通じて明らかになり、システムに追加されます。
デフォルトの質問集は YAML ファイルにエクスポートできます。
例7.1 Legacy Pathfinder YAML ファイル
name: Legacy Pathfinder
description: ''
sections:
- order: 1
name: Application details
questions:
- order: 1
text: >-
Does the application development team understand and actively develop
the application?
explanation: >-
How much knowledge does the team have about the application's
development or usage?
answers:
- order: 2
text: >-
Maintenance mode, no SME knowledge or adequate documentation
available
risk: red
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
Little knowledge, no development (example: third-party or
commercial off-the-shelf application)
risk: red
rationale: ''
mitigation: ''
- order: 3
text: Maintenance mode, SME knowledge is available
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Actively developed, SME knowledge is available
risk: green
rationale: ''
mitigation: ''
- order: 5
text: greenfield application
risk: green
rationale: ''
mitigation: ''
- order: 2
text: How is the application supported in production?
explanation: >-
Does the team have sufficient knowledge to support the application in
production?
answers:
- order: 3
text: >-
Multiple teams provide support using an established escalation
model
risk: yellow
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
External support provider with a ticket-driven escalation process;
no inhouse support resources
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Separate internal support team, separate from the development
team, with little interaction between the teams
risk: red
rationale: ''
mitigation: ''
- order: 4
text: >-
SRE (Site Reliability Engineering) approach with a knowledgeable
and experienced operations team
risk: green
rationale: ''
mitigation: ''
- order: 5
text: >-
DevOps approach with the same team building the application and
supporting it in production
risk: green
rationale: ''
mitigation: ''
- order: 3
text: >-
How much time passes from when code is committed until the application
is deployed to production?
explanation: What is the development latency?
answers:
- order: 3
text: 2-6 months
risk: yellow
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Not tracked
risk: red
rationale: ''
mitigation: ''
- order: 2
text: More than 6 months
risk: red
rationale: ''
mitigation: ''
- order: 4
text: 8-30 days
risk: green
rationale: ''
mitigation: ''
- order: 5
text: 1-7 days
risk: green
rationale: ''
mitigation: ''
- order: 6
text: Less than 1 day
risk: green
rationale: ''
mitigation: ''
- order: 4
text: How often is the application deployed to production?
explanation: Deployment frequency
answers:
- order: 3
text: Between once a month and once every 6 months
risk: yellow
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Not tracked
risk: red
rationale: ''
mitigation: ''
- order: 2
text: Less than once every 6 months
risk: red
rationale: ''
mitigation: ''
- order: 4
text: Weekly
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Daily
risk: green
rationale: ''
mitigation: ''
- order: 6
text: Several times a day
risk: green
rationale: ''
mitigation: ''
- order: 5
text: >-
What is the application's mean time to recover (MTTR) from failure in
a production environment?
explanation: Average time for the application to recover from failure
answers:
- order: 5
text: Less than 1 hour
risk: green
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Not tracked
risk: red
rationale: ''
mitigation: ''
- order: 3
text: 1-7 days
risk: yellow
rationale: ''
mitigation: ''
- order: 2
text: 1 month or more
risk: red
rationale: ''
mitigation: ''
- order: 4
text: 1-24 hours
risk: green
rationale: ''
mitigation: ''
- order: 6
text: Does the application have legal and/or licensing requirements?
explanation: >-
Legal and licensing requirements must be assessed to determine their
possible impact (cost, fault reporting) on the container platform
hosting the application. Examples of legal requirements: isolated
clusters, certifications, compliance with the Payment Card Industry
Data Security Standard or the Health Insurance Portability and
Accountability Act. Examples of licensing requirements: per server,
per CPU.
answers:
- order: 1
text: Multiple legal and licensing requirements
risk: red
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 2
text: 'Licensing requirements (examples: per server, per CPU)'
risk: red
rationale: ''
mitigation: ''
- order: 3
text: >-
Legal requirements (examples: cluster isolation, hardware, PCI or
HIPAA compliance)
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: None
risk: green
rationale: ''
mitigation: ''
- order: 7
text: Which model best describes the application architecture?
explanation: Describe the application architecture in simple terms.
answers:
- order: 3
text: >-
Complex monolith, strict runtime dependency startup order,
non-resilient architecture
risk: yellow
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 5
text: Independently deployable components
risk: green
rationale: ''
mitigation: ''
- order: 1
text: >-
Massive monolith (high memory and CPU usage), singleton
deployment, vertical scale only
risk: yellow
rationale: ''
mitigation: ''
- order: 2
text: >-
Massive monolith (high memory and CPU usage), non-singleton
deployment, complex to scale horizontally
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: 'Resilient monolith (examples: retries, circuit breakers)'
risk: green
rationale: ''
mitigation: ''
- order: 2
name: Application dependencies
questions:
- order: 1
text: Does the application require specific hardware?
explanation: >-
OpenShift Container Platform runs only on x86, IBM Power, or IBM Z
systems
answers:
- order: 3
text: 'Requires specific computer hardware (examples: GPUs, RAM, HDDs)'
risk: yellow
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Requires CPU that is not supported by red Hat
risk: red
rationale: ''
mitigation: ''
- order: 2
text: 'Requires custom or legacy hardware (example: USB device)'
risk: red
rationale: ''
mitigation: ''
- order: 4
text: Requires CPU that is supported by red Hat
risk: green
rationale: ''
mitigation: ''
- order: 2
text: What operating system does the application require?
explanation: >-
Only Linux and certain Microsoft Windows versions are supported in
containers. Check the latest versions and requirements.
answers:
- order: 4
text: Microsoft Windows
risk: yellow
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
Operating system that is not compatible with OpenShift Container
Platform (examples: OS X, AIX, Unix, Solaris)
risk: red
rationale: ''
mitigation: ''
- order: 2
text: Linux with custom kernel drivers or a specific kernel version
risk: red
rationale: ''
mitigation: ''
- order: 3
text: 'Linux with custom capabilities (examples: seccomp, root access)'
risk: yellow
rationale: ''
mitigation: ''
- order: 5
text: Standard Linux distribution
risk: green
rationale: ''
mitigation: ''
- order: 3
text: >-
Does the vendor provide support for a third-party component running in
a container?
explanation: Will the vendor support a component if you run it in a container?
answers:
- order: 2
text: No vendor support for containers
risk: red
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Not recommended to run the component in a container
risk: red
rationale: ''
mitigation: ''
- order: 3
text: >-
Vendor supports containers but with limitations (examples:
functionality is restricted, component has not been tested)
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: >-
Vendor supports their application running in containers but you
must build your own images
risk: yellow
rationale: ''
mitigation: ''
- order: 5
text: Vendor fully supports containers, provides certified images
risk: green
rationale: ''
mitigation: ''
- order: 6
text: No third-party components required
risk: green
rationale: ''
mitigation: ''
- order: 4
text: Incoming/northbound dependencies
explanation: Systems or applications that call the application
answers:
- order: 3
text: >-
Many dependencies exist, can be changed because the systems are
internally managed
risk: green
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 4
text: Internal dependencies only
risk: green
rationale: ''
mitigation: ''
- order: 1
text: >-
Dependencies are difficult or expensive to change because they are
legacy or third-party
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Many dependencies exist, can be changed but the process is
expensive and time-consuming
risk: yellow
rationale: ''
mitigation: ''
- order: 5
text: No incoming/northbound dependencies
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Outgoing/southbound dependencies
explanation: Systems or applications that the application calls
answers:
- order: 3
text: Application not ready until dependencies are verified available
risk: yellow
rationale: ''
mitigation: ''
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
Dependency availability only verified when application is
processing traffic
risk: red
rationale: ''
mitigation: ''
- order: 2
text: Dependencies require a complex and strict startup order
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Limited processing available if dependencies are unavailable
risk: green
rationale: ''
mitigation: ''
- order: 5
text: No outgoing/southbound dependencies
risk: green
rationale: ''
mitigation: ''
- order: 3
name: Application architecture
questions:
- order: 1
text: >-
How resilient is the application? How well does it recover from
outages and restarts?
explanation: >-
If the application or one of its dependencies fails, how does the
application recover from failure? Is manual intervention required?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
Application cannot be restarted cleanly after failure, requires
manual intervention
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Application fails when a soutbound dependency is unavailable and
does not recover automatically
risk: red
rationale: ''
mitigation: ''
- order: 3
text: >-
Application functionality is limited when a dependency is
unavailable but recovers when the dependency is available
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: >-
Application employs resilient architecture patterns (examples:
circuit breakers, retry mechanisms)
risk: green
rationale: ''
mitigation: ''
- order: 5
text: >-
Application containers are randomly terminated to test resiliency;
chaos engineering principles are followed
risk: green
rationale: ''
mitigation: ''
- order: 2
text: How does the external world communicate with the application?
explanation: >-
What protocols do external clients use to communicate with the
application?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: 'Non-TCP/IP protocols (examples: serial, IPX, AppleTalk)'
risk: red
rationale: ''
mitigation: ''
- order: 2
text: TCP/IP, with host name or IP address encapsulated in the payload
risk: red
rationale: ''
mitigation: ''
- order: 3
text: 'TCP/UDP without host addressing (example: SSH)'
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: TCP/UDP encapsulated, using TLS with SNI header
risk: green
rationale: ''
mitigation: ''
- order: 5
text: HTTP/HTTPS
risk: green
rationale: ''
mitigation: ''
- order: 3
text: How does the application manage its internal state?
explanation: >-
If the application must manage or retain an internal state, how is
this done?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 3
text: State maintained in non-shared, non-ephemeral storage
risk: yellow
rationale: ''
mitigation: ''
- order: 1
text: Application components use shared memory within a pod
risk: yellow
rationale: ''
mitigation: ''
- order: 2
text: >-
State is managed externally by another product (examples:
Zookeeper or red Hat Data Grid)
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Disk shared between application instances
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Stateless or ephemeral container storage
risk: green
rationale: ''
mitigation: ''
- order: 4
text: How does the application handle service discovery?
explanation: How does the application discover services?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
Uses technologies that are not compatible with Kubernetes
(examples: hardcoded IP addresses, custom cluster manager)
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Requires an application or cluster restart to discover new service
instances
risk: red
rationale: ''
mitigation: ''
- order: 3
text: >-
Uses technologies that are compatible with Kubernetes but require
specific libraries or services (examples: HashiCorp Consul,
Netflix Eureka)
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Uses Kubernetes DNS name resolution
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Does not require service discovery
risk: green
rationale: ''
mitigation: ''
- order: 5
text: How is the application clustering managed?
explanation: >-
Does the application require clusters? If so, how is clustering
managed?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: 'Manually configured clustering (example: static clusters)'
risk: red
rationale: ''
mitigation: ''
- order: 2
text: Managed by an external off-PaaS cluster manager
risk: red
rationale: ''
mitigation: ''
- order: 3
text: >-
Managed by an application runtime that is compatible with
Kubernetes
risk: green
rationale: ''
mitigation: ''
- order: 4
text: No cluster management required
risk: green
rationale: ''
mitigation: ''
- order: 4
name: Application observability
questions:
- order: 1
text: How does the application use logging and how are the logs accessed?
explanation: How the application logs are accessed
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Logs are unavailable or are internal with no way to export them
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Logs are in a custom binary format, exposed with non-standard
protocols
risk: red
rationale: ''
mitigation: ''
- order: 3
text: Logs are exposed using syslog
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Logs are written to a file system, sometimes as multiple files
risk: yellow
rationale: ''
mitigation: ''
- order: 5
text: 'Logs are forwarded to an external logging system (example: Splunk)'
risk: green
rationale: ''
mitigation: ''
- order: 6
text: 'Logs are configurable (example: can be sent to stdout)'
risk: green
rationale: ''
mitigation: ''
- order: 2
text: Does the application provide metrics?
explanation: >-
Are application metrics available, if necessary (example: OpenShift
Container Platform collects CPU and memory metrics)?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: No metrics available
risk: yellow
rationale: ''
mitigation: ''
- order: 2
text: Metrics collected but not exposed externally
risk: yellow
rationale: ''
mitigation: ''
- order: 3
text: 'Metrics exposed using binary protocols (examples: SNMP, JMX)'
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: >-
Metrics exposed using a third-party solution (examples: Dynatrace,
AppDynamics)
risk: green
rationale: ''
mitigation: ''
- order: 5
text: >-
Metrics collected and exposed with built-in Prometheus endpoint
support
risk: green
rationale: ''
mitigation: ''
- order: 3
text: >-
How easy is it to determine the application's health and readiness to
handle traffic?
explanation: >-
How do we determine an application's health (liveness) and readiness
to handle traffic?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: No health or readiness query functionality available
risk: red
rationale: ''
mitigation: ''
- order: 3
text: Basic application health requires semi-complex scripting
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Dedicated, independent liveness and readiness endpoints
risk: green
rationale: ''
mitigation: ''
- order: 2
text: Monitored and managed by a custom watchdog process
risk: red
rationale: ''
mitigation: ''
- order: 5
text: Health is verified by probes running synthetic transactions
risk: green
rationale: ''
mitigation: ''
- order: 4
text: What best describes the application's runtime characteristics?
explanation: >-
How would the profile of an application appear during runtime
(examples: graphs showing CPU and memory usage, traffic patterns,
latency)? What are the implications for a serverless application?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
Deterministic and predictable real-time execution or control
requirements
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Sensitive to latency (examples: voice applications, high frequency
trading applications)
risk: yellow
rationale: ''
mitigation: ''
- order: 3
text: Constant traffic with a broad range of CPU and memory usage
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Intermittent traffic with predictable CPU and memory usage
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Constant traffic with predictable CPU and memory usage
risk: green
rationale: ''
mitigation: ''
- order: 5
text: How long does it take the application to be ready to handle traffic?
explanation: How long the application takes to boot
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: More than 5 minutes
risk: red
rationale: ''
mitigation: ''
- order: 2
text: 2-5 minutes
risk: yellow
rationale: ''
mitigation: ''
- order: 3
text: 1-2 minutes
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: 10-60 seconds
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Less than 10 seconds
risk: green
rationale: ''
mitigation: ''
- order: 5
name: Application cross-cutting concerns
questions:
- order: 1
text: How is the application tested?
explanation: >-
Is the application is tested? Is it easy to test (example: automated
testing)? Is it tested in production?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: No testing or minimal manual testing only
risk: red
rationale: ''
mitigation: ''
- order: 2
text: Minimal automated testing, focused on the user interface
risk: yellow
rationale: ''
mitigation: ''
- order: 3
text: >-
Some automated unit and regression testing, basic CI/CD pipeline
testing; modern test practices are not followed
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: >-
Highly repeatable automated testing (examples: unit, integration,
smoke tests) before deploying to production; modern test practices
are followed
risk: green
rationale: ''
mitigation: ''
- order: 5
text: >-
Chaos engineering approach, constant testing in production
(example: A/B testing + experimentation)
risk: green
rationale: ''
mitigation: ''
- order: 2
text: How is the application configured?
explanation: >-
How is the application configured? Is the configuration method
appropriate for a container? External servers are runtime
dependencies.
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: >-
Configuration files compiled during installation and configured
using a user interface
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Configuration files are stored externally (example: in a database)
and accessed using specific environment keys (examples: host name,
IP address)
risk: red
rationale: ''
mitigation: ''
- order: 3
text: Multiple configuration files in multiple file system locations
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: >-
Configuration files built into the application and enabled using
system properties at runtime
risk: yellow
rationale: ''
mitigation: ''
- order: 5
text: >-
Configuration retrieved from an external server (examples: Spring
Cloud Config Server, HashiCorp Consul)
risk: yellow
rationale: ''
mitigation: ''
- order: 6
text: >-
Configuration loaded from files in a single configurable location;
environment variables used
risk: green
rationale: ''
mitigation: ''
- order: 4
text: How is the application deployed?
explanation: >-
How the application is deployed and whether the deployment process is
suitable for a container platform
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 3
text: Simple automated deployment scripts
risk: yellow
rationale: ''
mitigation: ''
- order: 1
text: Manual deployment using a user interface
risk: red
rationale: ''
mitigation: ''
- order: 2
text: Manual deployment with some automation
risk: red
rationale: ''
mitigation: ''
- order: 4
text: >-
Automated deployment with manual intervention or complex promotion
through pipeline stages
risk: yellow
rationale: ''
mitigation: ''
- order: 5
text: >-
Automated deployment with a full CI/CD pipeline, minimal
intervention for promotion through pipeline stages
risk: green
rationale: ''
mitigation: ''
- order: 6
text: Fully automated (GitOps), blue-green, or canary deployment
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Where is the application deployed?
explanation: Where does the application run?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Bare metal server
risk: green
rationale: ''
mitigation: ''
- order: 2
text: 'Virtual machine (examples: red Hat Virtualization, VMware)'
risk: green
rationale: ''
mitigation: ''
- order: 3
text: 'Private cloud (example: red Hat OpenStack Platform)'
risk: green
rationale: ''
mitigation: ''
- order: 4
text: >-
Public cloud provider (examples: Amazon Web Services, Microsoft
Azure, Google Cloud Platform)
risk: green
rationale: ''
mitigation: ''
- order: 5
text: >-
Platform as a service (examples: Heroku, Force.com, Google App
Engine)
risk: yellow
rationale: ''
mitigation: ''
- order: 7
text: Other. Specify in the comments field
risk: yellow
rationale: ''
mitigation: ''
- order: 6
text: Hybrid cloud (public and private cloud providers)
risk: green
rationale: ''
mitigation: ''
- order: 6
text: How mature is the containerization process, if any?
explanation: If the team has used containers in the past, how was it done?
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Application runs in a container on a laptop or desktop
risk: red
rationale: ''
mitigation: ''
- order: 3
text: Some experience with containers but not yet fully defined
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: >-
Proficient with containers and container platforms (examples:
Swarm, Kubernetes)
risk: green
rationale: ''
mitigation: ''
- order: 5
text: Application containerization has not yet been attempted
risk: green
rationale: ''
mitigation: ''
- order: 3
text: How does the application acquire security keys or certificates?
explanation: >-
How does the application retrieve credentials, keys, or certificates?
External systems are runtime dependencies.
answers:
- order: 0
text: unknown
risk: unknown
rationale: ''
mitigation: ''
- order: 1
text: Hardware security modules or encryption devices
risk: red
rationale: ''
mitigation: ''
- order: 2
text: >-
Keys/certificates bound to IP addresses and generated at runtime
for each application instance
risk: red
rationale: ''
mitigation: ''
- order: 3
text: Keys/certificates compiled into the application
risk: yellow
rationale: ''
mitigation: ''
- order: 4
text: Loaded from a shared disk
risk: yellow
rationale: ''
mitigation: ''
- order: 5
text: >-
Retrieved from an external server (examples: HashiCorp Vault,
CyberArk Conjur)
risk: yellow
rationale: ''
mitigation: ''
- order: 6
text: Loaded from files
risk: green
rationale: ''
mitigation: ''
- order: 7
text: Not required
risk: green
rationale: ''
mitigation: ''
thresholds:
red: 5
yellow: 30
unknown: 5
riskMessages:
red: ''
yellow: ''
green: ''
unknown: ''
builtin: true7.2.2. カスタムのアセスメント質問集
Migration Toolkit for Applications (MTA) を使用すると、カスタムの YAML 構文を使用して質問集を定義し、カスタムのアセスメント質問集をインポートできます。YAML 構文は次の機能をサポートしています。
- 条件付きの質問
YAML 構文は、アプリケーションまたはアーキタイプに存在するタグに基づく質問の追加または除外をサポートします。次に例を示します。
アプリケーションまたはアーキタイプに
Language/Javaタグがある場合に、What is the main JAVA framework used in your application?という質問を質問集に追加します。... questions: - order: 1 text: What is the main JAVA framework used in your application? explanation: Identify the primary JAVA framework used in your application. includeFor: - category: Language tag: Java ...アプリケーションまたはアーキタイプに
Deployment/ServerlessおよびArchitecture/Monolithタグがある場合に、Are you currently using any form of container orchestration?という質問を質問集から除外します。... questions: - order: 4 text: Are you currently using any form of container orchestration? explanation: Determine if the application utilizes container orchestration tools like Kubernetes, Docker Swarm, etc. excludeFor: - category: Deployment tag: Serverless - category: Architecture tag: Monolith ...
- 評価対象のアプリケーションまたはアーキタイプに存在するタグに基づく自動回答
自動回答は、アプリケーションまたはアーキタイプに存在するタグに基づいて選択されます。たとえば、アプリケーションまたはアーキタイプに
Runtime/Quarkusタグがある場合は、Quarkusの回答が自動的に選択され、アプリケーションまたはアーキタイプにRuntime/Spring Bootタグがある場合は、Spring Bootの回答が自動的に選択されます。... text: What is the main technology in your application? explanation: Identify the main framework or technology used in your application. answers: - order: 1 text: Quarkus risk: green autoAnswerFor: - category: Runtime tag: Quarkus - order: 2 text: Spring Boot risk: green autoAnswerFor: - category: Runtime tag: Spring Boot ...- 回答に基づいたアプリケーションの自動タグ付け
アセスメント中に、回答が選択されると、その回答に基づいてアプリケーションまたはアーキタイプにタグが自動的に適用されます。タグは推移的であることに注意してください。したがって、アセスメントが破棄されるとタグは削除されます。各タグは次の要素によって定義されます。
-
category: 対象タグのカテゴリー (
文字列)。 -
tag: ターゲットタグの定義 (
String)。
たとえば、選択した回答が
Quarkusの場合、評価対象のアプリケーションまたはアーキタイプにRuntime/Quarkusタグが適用されます。選択した回答がSpring Bootの場合、Runtime/Spring Bootタグが評価対象のアプリケーションまたはアーキタイプに適用されます。... questions: - order: 1 text: What is the main technology in your application? explanation: Identify the main framework or technology used in your application. answers: - order: 1 text: Quarkus risk: green applyTags: - category: Runtime tag: Quarkus - order: 2 text: Spring Boot risk: green applyTags: - category: Runtime tag: Spring Boot ...-
category: 対象タグのカテゴリー (
7.2.2.1. カスタム質問集の YAML テンプレート
次の YAML テンプレートを使用して、カスタムの質問集をビルドできます。このテンプレートは、Assessment questionnaires ページで Download YAML template をクリックするとダウンロードできます。
例7.2 カスタム質問集の YAML テンプレート
name: Uploadable Cloud Readiness Questionnaire Template
description: This questionnaire is an example template for assessing cloud readiness. It serves as a guide for users to create and customize their own questionnaire templates.
required: true
sections:
- order: 1
name: Application Technologies
questions:
- order: 1
text: What is the main technology in your application?
explanation: Identify the main framework or technology used in your application.
includeFor:
- category: Language
tag: Java
answers:
- order: 1
text: Quarkus
risk: green
rationale: Quarkus is a modern, container-friendly framework.
mitigation: No mitigation needed.
applyTags:
- category: Runtime
tag: Quarkus
autoAnswerFor:
- category: Runtime
tag: Quarkus
- order: 2
text: Spring Boot
risk: green
rationale: Spring Boot is versatile and widely used.
mitigation: Ensure container compatibility.
applyTags:
- category: Runtime
tag: Spring Boot
autoAnswerFor:
- category: Runtime
tag: Spring Boot
- order: 3
text: Legacy Monolithic Application
risk: red
rationale: Legacy monoliths are challenging for cloud adaptation.
mitigation: Consider refactoring into microservices.
- order: 2
text: Does your application use a microservices architecture?
explanation: Assess if the application is built using a microservices architecture.
answers:
- order: 1
text: Yes
risk: green
rationale: Microservices are well-suited for cloud environments.
mitigation: Continue monitoring service dependencies.
- order: 2
text: No
risk: yellow
rationale: Non-microservices architectures may face scalability issues.
mitigation: Assess the feasibility of transitioning to microservices.
- order: 3
text: Unknown
risk: unknown
rationale: Lack of clarity on architecture can lead to unplanned issues.
mitigation: Conduct an architectural review.
- order: 3
text: Is your application's data storage cloud-optimized?
explanation: Evaluate if the data storage solution is optimized for cloud usage.
includeFor:
- category: Language
tag: Java
answers:
- order: 1
text: Cloud-Native Storage Solution
risk: green
rationale: Cloud-native solutions offer scalability and resilience.
mitigation: Ensure regular backups and disaster recovery plans.
- order: 2
text: Traditional On-Premises Storage
risk: red
rationale: Traditional storage might not scale well in the cloud.
mitigation: Explore cloud-based storage solutions.
- order: 3
text: Hybrid Storage Approach
risk: yellow
rationale: Hybrid solutions may have integration complexities.
mitigation: Evaluate and optimize cloud integration points.
thresholds:
red: 1
yellow: 30
unknown: 15
riskMessages:
red: Requires deep changes in architecture or lifecycle
yellow: Cloud friendly but needs minor changes
green: Cloud Native
unknown: More information needed関連情報
7.2.2.2. カスタム質問集のフィールド
required とマークしたカスタム質問集のフィールドはすべて必須であり、入力する必要があります。記入しないと、アップロード時に YAML 構文が検証されません。フィールドの各サブセクションは、YAML で新しい構造体またはオブジェクトを定義します。次に例を示します。
...
name: Testing
thresholds:
red: 30
yellow: 45
unknown: 5
...| 質問集のフィールド | 説明 |
|---|---|
|
| 質問集の名前。このフィールドは、MTA インスタンス全体で一意である必要があります。 |
|
| 質問集の簡単な説明。 |
|
| リスクレベルの影響を受けると考えられるアプリケーションまたはアーキタイプの、リスクカテゴリーごとのしきい値の定義。しきい値は次のとおりです。
より高いリスクレベルが常に優先されます。たとえば、 |
|
| 各リスクカテゴリーのレポートに表示されるメッセージ。risk_messages マップは次のフィールドで定義されます。
|
|
| 質問集に含める必要があるセクションのリスト。
|
関連情報
