Professional Cloud DevOps 练习题 — DevOps 工程师 - 专业级

题目要求预测GKE上Node.js应用的依赖应用的性能问题，核心需求是识别跨服务调用链路中各依赖服务的响应耗时情况，找到潜在性能瓶颈。Stackdriver Trace（现Cloud Trace）是Google Cloud提供的托管式分布式追踪服务，可通过简单埋点自动采集跨服务的请求全链路数据，包含每个服务间HTTP请求的耗时、状态等信息，无需大量自定义开发即可快速定位哪个依赖服务存在响应过慢的问题，完全匹配题目需求，符合DevOps可观测性领域的最佳实践。 各选项分析： A. Stackdriver Profiler（现Cloud Profiler）的核心作用是分析单个应用内部的CPU、内存、函数执行耗时等运行时性能数据，用于排查单应用内部的性能瓶颈，无法采集跨服务依赖的调用性能数据，不能满足识别依赖应用性能问题的需求，因此A错误。 B. Stackdriver Trace专为分布式架构下的请求链路追踪设计，对所有应用埋点后可采集完整的服务间HTTP调用数据，通过审查各调用的耗时即可快速识别出可能存在性能问题的依赖应用，完全匹配题目需求，因此B正确。 C. Stackdriver Debugger（现Cloud Debugger）的核心作用是在不中断生产服务运行的前提下，采集应用代码运行时的变量、堆栈等调试信息，用于排查代码逻辑错误，不具备性能分析尤其是跨服务依赖性能分析的能力，因此C错误。 D. 自定义修改应用代码记录请求和响应时间的方案虽然可实现需求，但需要侵入业务代码开发，后续维护成本高，且不符合Google Cloud DevOps优先使用托管可观测性服务的最佳实践，不是最优解决方案，因此D错误。 关键知识点： 1. Google Cloud可观测性工具的适用场景：需明确Trace、Profiler、Debugger、Logging四款核心工具的不同用途，其中Trace用于分布式链路追踪，Profiler用于单应用内部性能剖析，Debugger用于生产代码调试，Logging用于日志采集分析。 2. 分布式追踪的核心价值：在微服务架构下，分布式追踪可采集跨服务请求的全链路耗时数据，快速定位链路中的性能瓶颈依赖，是微服务性能监控的核心手段。 3. GKE应用可观测性最佳实践：优先使用Google Cloud托管的可观测性服务，减少对业务代码的侵入，降低运维和开发成本。 参考资料： 1. Cloud Trace 概述, 2. GKE 运行最佳实践：可观测性

本题考察Google Cloud DevOps中Cloud Monitoring（原Stackdriver）的共享机制与IAM最小权限原则的结合应用。题目要求仅向SRE团队共享单个CPU利用率图表，同时遵循最小权限。首先，通过URL共享单个图表可以定向提供目标图表的访问入口，避免SRE团队接触到工作区中的其他无关监控内容，符合仅共享指定图表的需求。其次，访问图表中的CPU利用率指标数据需要对应监控指标的读取权限，Monitoring Viewer角色刚好具备读取监控时序数据、指标描述的最低权限，无修改监控配置的权限，完全满足查看单张监控图表的需求，符合最小权限要求。 各选项分析： A. 错误。直接共享工作区项目ID会向SRE团队开放整个工作区的访问入口，SRE可以浏览工作区内所有监控内容，超出仅共享单个图表的需求，违反最小权限原则。 B. 错误。首先共享工作区项目ID就存在权限范围过大的问题，其次Dashboard Viewer角色仅具备查看仪表板配置的权限，没有读取底层监控指标数据的权限，SRE即使拿到工作区访问入口也无法查看图表中的CPU利用率数据，无法满足需求。 C. 正确。通过URL共享单个图表定向提供了目标图表的唯一访问入口，避免暴露无关监控内容。分配Monitoring Viewer角色为SRE团队授予了查看监控指标数据的最低必要权限，既可以正常查看该CPU利用率图表，又没有多余的修改或访问其他非授权内容的权限，完全符合题目要求。 D. 错误。Dashboard Viewer角色没有读取监控时序数据的权限，即使获取了图表的共享URL，也无法加载显示图表中的CPU利用率实际数据，无法满足查看图表的需求。 关键知识点： 1. IAM最小权限原则：为用户授予完成其工作任务所需的最低级别、最小范围的权限，避免过度授权带来的安全风险，是DevOps运维安全的核心原则之一。 2. Cloud Monitoring IAM角色权限划分：Monitoring Viewer角色拥有查看监控指标数据、告警配置等监控内容的只读权限，Dashboard Viewer角色仅拥有查看仪表板结构配置的权限，无底层监控指标数据的读取权限。 3. Cloud Monitoring图表共享机制：单个监控图表可通过生成专属URL的方式定向共享，仅获取该URL的用户可以直接访问目标图表，无需暴露整个监控工作区的访问入口。 参考资料： Cloud Monitoring 访问控制指南, https://cloud.google.com/monitoring/access-control Cloud Monitoring 共享图表官方文档

本题考察站点可靠性工程SRE文化中事后分析的核心原则，属于Google Cloud Professional Cloud DevOps Engineer认证的核心考点。SRE事后分析的核心目标是沉淀故障经验、避免同类问题重复发生，而非追责个人，因此需要遵循两大核心要求，一是坚持无指责文化，事后分析内容不包含个人追责相关信息，二是事后分析成果要在工程组织内广泛共享，让所有团队都能吸取经验，而非仅提供给单个请求的经理，最大化故障的学习价值，助力整体SRE文化落地。 各选项分析： A. 错误。该选项仅将事后分析分享给单个经理，不符合SRE知识全组织共享的原则，其他团队无法学习该故障的经验教训，无法避免同类问题在其他业务中发生，没有实现故障的最大价值。 B. 正确。该选项的事后分析内容包含了标准SRE事后分析要求的根因、解决方案、经验教训、优先级行动项四大核心要素，没有追责个人的责任人名单，符合无指责文化，同时将报告发布到工程组织的文档门户网站，所有团队都可以查阅学习，能够最大化故障的价值，完全符合SRE的原则要求。 C. 错误。存在两个核心问题，一是报告包含责任人名单，违反SRE无指责的事后分析文化，会导致团队成员不敢暴露故障细节，反而不利于问题的根因挖掘；二是仅将报告分享给单个经理，共享范围过小，无法实现经验全组织复用的目标。 D. 错误。虽然共享范围符合要求，但报告包含责任人名单，违反SRE无指责的核心原则，会打击团队坦诚报告问题的积极性，不符合SRE文化建设要求。 关键知识点： 1. SRE无指责事后分析原则：事后分析聚焦于识别系统、流程层面的缺陷，不追究个人责任，鼓励团队无压力地披露故障全链路信息，保障根因分析的完整性。 2. SRE知识共享原则：故障事后分析成果需要在组织内广泛公开，确保所有业务团队都能吸取经验教训，降低全组织同类故障的发生概率。 3. 标准SRE事后分析核心要素：合格的事后分析需包含根因分析、修复方案、经验教训、按优先级排序的行动事项四个核心部分，无需记录个人责任相关内容。 参考资料： 1. Site Reliability Engineering: Postmortem Culture: Learning from Failure, https://sre.google/sre-book/postmortem-culture/ 2. Google Cloud DevOps 最佳实践: 可靠性与事后分析

本题核心需求是将不可修改的第三方应用输出到容器内/var/log/app_messages.log的日志采集到Stackdriver Logging，且运行环境是已有的GKE集群。GKE默认的日志采集仅覆盖容器标准输出和标准错误，无法直接采集自定义路径的文件日志。选项B采用Fluentd DaemonSet方案，是GKE自定义日志采集的官方推荐方案，Fluentd作为云原生标准日志采集工具，DaemonSet部署模式可在每个集群节点运行一个采集实例，通过挂载节点上的Pod存储目录可以访问所有Pod内的日志文件，自定义输入配置即可精准匹配目标应用的日志文件路径，再通过内置的Stackdriver输出插件直接将日志投递到Stackdriver Logging，全程不需要修改第三方应用，也无需对现有GKE集群做大规模调整，完全满足题目所有需求，符合DevOps轻量化、低侵入的运维原则。 各选项分析： A. 错误。默认的Stackdriver Kubernetes Engine Monitoring代理仅采集容器的标准输出、标准错误日志，以及Kubernetes系统组件、节点的系统日志，不会主动采集容器内自定义路径的文件日志，无法满足需求。 B. 正确。Fluentd是GKE官方支持的日志采集组件，以DaemonSet方式部署可以实现节点级统一日志采集，无需为每个Pod额外部署组件，通过自定义输入配置可以识别采集应用Pod内/var/log/app_messages.log的日志内容，再通过内置的Stackdriver输出插件直接投递到Stackdriver Logging，无需修改第三方应用，资源开销低，运维复杂度低，完全符合需求。 C. 错误。现有环境已经是托管的GKE集群，自行在GCE上部署Kubernetes会大幅提升运维成本，完全没有必要，不符合托管服务降本提效的DevOps最佳实践。 D. 错误。sidecar方案虽然可以实现日志采集，但需要为每个应用Pod额外部署sidecar容器，资源开销远高于DaemonSet的节点级统一采集方案，且运维复杂度更高，不属于本题的最优解法。 关键知识点： 1. GKE默认日志采集范围：Cloud Operations for GKE默认仅采集容器标准输出、标准错误，节点系统日志和Kubernetes组件日志，自定义路径的容器内文件日志需要额外配置采集规则。 2. Kubernetes日志采集方案选型：节点级DaemonSet日志代理方案适合集群全量或多应用的统一日志采集，相比sidecar模式资源利用率更高，运维更统一，是云原生场景下的首选通用日志采集方案。 3. Stackdriver Logging集成能力：Fluentd官方内置Stackdriver Logging输出插件，可直接将采集到的日志结构化投递到Cloud Logging服务，无需额外开发适配。 参考资料： 1. 为 GKE 配置自定义日志记录, 2. Cloud Operations for GKE 概览

本题考察Cloud Logging（原Stackdriver Logging）代理的排错逻辑，属于DevOps工程师日常运维的基础场景。排查VM日志不上报问题时需遵循从本地到云端的优先级，首先确认本地日志收集代理是否正常运行，再依次排查配置、权限、网络等问题。Stackdriver Logging代理底层基于Fluentd实现，通过ps命令查找fluentd进程可快速验证代理是否处于运行状态，这是所有后续排查动作的前提，因此应作为第一步操作。 各选项分析： A. 错误。代理的测试日志条目存在的前提是代理已正常运行，若代理本身未启动，不存在对应的测试日志，因此该操作不能作为第一步排查动作。 B. 错误。直接安装最新版本代理属于无前置验证的盲目操作，未确认是否是代理版本导致的问题前不应执行该操作，且若代理未运行，重装版本无法从根本上解决问题。 C. 错误。首先，日志上报需要的是logging.write访问范围，monitoring.write是监控指标上报所需的权限，范围本身不匹配；其次访问范围属于云端权限类问题，优先级低于本地代理运行状态排查，不应作为第一步。 D. 正确。Stackdriver Logging代理基于Fluentd构建，执行ps ax | grep fluentd可直接验证代理进程是否正常运行，是日志不上报问题的首个排查步骤，只有确认代理运行正常后才有必要开展后续排查。 关键知识点： 1. Google Cloud Logging代理（原Stackdriver Logging代理）基于Fluentd开源组件开发，负责收集虚拟机上的syslog、应用日志等数据并上传到Cloud Logging服务。 2. 云原生运维排错遵循从本地到云端的优先级，对于VM日志不上报问题，优先排查本地代理运行状态，再依次排查配置、权限、网络等问题。 3. 虚拟机的服务帐号访问范围控制实例调用Google Cloud API的权限，日志上报需要logging.write权限，monitoring.write权限仅用于监控指标数据的上报。 参考资料： 1. Troubleshooting the Logging agent, 2. Cloud Logging agent overview