红帽全球峰会7.2. MTA 评估问题
Migration Toolkit for Applications (MTA)使用评估问题( default 或 custom )来评估应用程序容器化的风险。
评估报告提供有关与迁移相关的应用程序和风险的信息。该报告还通过提交评估的应用程序的优先级别、业务关键性和依赖项生成采用计划。
7.2.1. 默认评估问题
传统的 Pathfinder 是应用程序(MTA)问题的默认 Migration Toolkit。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 语法支持根据应用程序上的现有标签或 archetype 包括或排除问题，例如：
如果应用程序或 archetype 具有
Language/Java标签，则应用程序中使用的主 JAVA 框架是什么？问题包括在问题中：... 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 ...如果应用程序或 archetype 具有
Deployment/Serverless和Architecture/Monolith标签，您当前使用任何形式的容器编配？问题不包括在问题中：... 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 ...
- 基于评估的应用程序或架构类型上的标签进行自动化答案
根据应用程序或 archetype 的现有标签选择自动回答。例如，如果应用程序或 archetype 具有
Runtime/Quarkus标签，则会自动选择Quarkus回答，如果应用程序或 archetype 具有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 ...- 根据回答自动标记应用程序
在评估过程中，如果选择了此答案，标签会根据答案自动应用到应用程序或架构类型。请注意，标签是传输的。因此，如果评估被丢弃，则会移除标签。每个标签由以下元素定义：
-
类别 ：目标标签(
字符串)的类别。 -
标签 ：目标标签定义为 (
字符串)。
例如，如果所选的答案是
Quarkus，则Runtime/Quarkus标签将应用到评估的应用程序或 archetype。如果所选答案是Spring Boot，则Runtime/Spring Boot标签将应用到评估的应用程序或 archetype：... 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 ...-
类别 ：目标标签(
7.2.2.1. 自定义问卷的 YAML 模板
您可以使用以下 YAML 模板来构建自定义问题。您可以点击 评估问题 页面中的 Download YAML 模板 下载此模板。
例 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. 自定义问题字段
每个标记为 必要的 自定义问题字段都是强制的，必须完成。否则，YAML 语法不会在上传时进行验证。字段的每个小节在 YAML 中定义一个新的结构或对象，例如：
...
name: Testing
thresholds:
red: 30
yellow: 45
unknown: 5
...| questionnaire 字段 | 描述 |
|---|---|
|
| 问题的名称。此字段对于整个 MTA 实例必须是唯一的。 |
|
| 问题的简短描述。 |
|
| 每个应用程序或架构类别的阈值的定义，它们被视为受该风险级别影响。阈值可以是以下：
更高的风险级别始终具有优先权。例如，如果 |
|
| 要显示在报告中每个风险类别的消息。risk_messages 映射由以下字段定义：
|
|
| 问题naire 必须包括的部分列表。
|
其他资源
