运维面试问题：发布上线回滚等

Question

用jenkins集成Kubernetes失败，节点显示离线状态
jenkins通过pod模板，配置k8s集群失败，节点显示离线状态,k8s 上创建了 pod失败：
权限不是问题，因为：在安装Jenkins的时候已经指定过serviceAccount,这个serviceAccount绑了ClusterRole，ClusterRole有权限。
测试连接的时候ok,显示：Connected to Kubernetes v1.16.2
但是节点显示离线状态

jenkins接入k8s 上创建了 pod失败
（1）Kubernetes 地址: https://kubernetes.default（2）Kubernetes 命名空间：jenkins
（3）服务证书不用写（我们在安装Jenkins的时候已经指定过serviceAccount,这个serviceAccount绑了ClusterRole，ClusterRole有权限。所以jenkins有权限读k8s的东西），均使用默认
（4）凭据:无，连接测试，成功会提示：Connected to Kubernetes v1.16.2
（5）Jenkins地址：http://jenkins:8080
（6）Jenkins 通道 ：jenkins:50000

配置Pod Template

（1）名称：jnlp-slave
（2）命名空间：jenkins
（3）标签列表：jnlp-slave，作为agent的label选择用
（4）连接 Jenkins 的超时时间（秒） ：300，
（5）节点选择器：agent=true
（6）给slave2打个标签
（7）修改jenkinsfile,并提交到git
agent { label 'jnlp-slave'}

配置是这样的，检查了很多遍，但是pod还是创建失败，怎么办？

---

面试问题怎么回答？急

您负责银行系统运营，并与研发和QA团队合作，使AWS云上的一切顺利进行。
团队有3个现场环境可供使用。
开发人员：供开发团队使用。将通过任何实现请求功能进行更新。
stag：用于向生产现场发布候选产品。该网站也将向一些合作伙伴开放，以确保新功能不会破坏他们
Prod：外部客户使用此生产服务的真实生产环境。
以下是您将遇到的一些情况：
1.现在，站点部署是手动的。
2.QA团队仅在部署完成时测试暂存站点。
3.从开发到生产环境的生产发布需要很长时间才能完成。
4.如果我们在生产中发现一些关键问题，很难回滚。
5.由于是一个银行系统，当我们有设计或架构更改时，需要进行安全审查，有些更改不容易察觉。
6.由于隐私和许可问题，研发团队很难调查生产现场问题。
7.如果QA团队需要在stag站点进行性能测试，将封锁stag站点以确保测试结果正确。

Answer 1

以下答案由GPT-4.5Plus大模型(语音)与博主A努力中.......共同编写：
这是一个典型的银行系统运维面试场景。我的回答如下:

1. 现在的手动部署方式效率低下,安全性和稳定性难以保证。我会推荐使用持续集成和自动化部署流程,通过Jenkins或CircleCI实现代码编译、测试、构建和部署的自动化。
2. QA团队应该采取持续测试的方式,随时测试最新的代码和配置变更,而不仅仅在部署完成后的一次性测试。我会建议使用自动化测试框架,在每次commit或merge请求时触发全部测试。
3. 长时间的生产发布周期会阻碍新功能的交付和Bug的修复。我会建议使用蓝绿部署的方式,新的版本部署至空闲环境进行测试,测试通过后快速切换流量。这样可以大幅缩短发布周期。
4. 采用蓝绿部署方式,可以在出现关键问题时快速回滚至旧版本,保证系统稳定性。同时,我也会推荐建立自动化监控,在出现关键Metric异常时自动触发回滚机制。
5. 针对系统架构或设计的重大更改,我会推荐采取最严格的审查流程,保证安全性。同时,也需要进行充分的测试验证,模拟各种架构更改后的场景和异步情况。
6. 研发团队访问生产环境确实存在隐私和安全隐患。我会建议通过严格的权限控制和审计机制进行管控。另外,也可以采取类生产环境的Staging环境进行问题调查和重现。
7. 性能测试会对Staging站点产生较大影响,但是为确保测试准确性,暂时关闭一段时间也在所难免。我会建议制定测试计划,避开高峰期;同时也提高Staging站点的扩展性,尽量减少性能测试对站点的影响。
   以上是我对该面试场景的分析和建议。总体来说,主要是推荐采用 DevOps的思想和工具,实现持续集成、自动化测试、蓝绿部署等,不断优化系统的交付效率、稳定性和安全性。同时也需要对审计、监控和测试等机制进行改进,确保系统的高可用。