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

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

img

img

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站点以确保测试结果正确。

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

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

可以看看

一、产品需求确认

涉及人员范围：产品经理、UI设计师、研发工程师、测试工程师、需求部门对接人；

需求控制负责人：业务功能接口产品经理(后台产品、前台产品)；

动作：

1、产品经理负责召集需求功能涉及人员进行需求宣讲，完成最终功能需求确认；

2、产品经理负责UI原型图上传至Gitlab，作为统一交付窗口提给研发；

3、产品经理根据已确定需求，沟通协调研发、测试完成排期预估，并在每周四向相关功能需求涉及人员公布最新的需求排期表；

交付：PRD文档、原型图、业务流程图、需求排期表。

二、产品研发

涉及人员范围：前端(IOS、Android、H5)研发工程师、后端(JAVA)研发工程师；

代码环境：DEV代码环境、本地代码环境(禁止超出代码环境范围)；

代码环境负责人：前端研发、后端研发；

引用chatgpt部分指引作答：
谈到这些问题时，可以从以下几个方面回答：

1、部署自动化 - 引入自动化工具：针对现在手动部署的情况，应该引引入自动化工具，例如Jenkins、Ansible等，以便快速确定更改内容，并在所有环境中进行部署。
2、测试并行进行 - 测试持续继承：为了避免部署后再次测试，QA团队需要采取持续集成方法，将检查过程自动化并与开发团队以及运维团队协同合作。
3、快速回滚 - 实施容器化：为了加快生产发布的速度，并实现以容器为中心的交付，这样就能够快速轻松地回滚。
4、安全审计 - 在流水线中包含安全细则：设计和架构更改时，应当始终考虑安全方案。将安全检查程序包含在自动化流水线中，以便随着正确性验证同时进行安全审查。
5、生产监控 - 实施日志监控解决方案：建议实现一种生产环境的监控系统，以便研发人员可以追踪并调查生产环境下的错误日志，相关修改无需传递给运维。
6、性能测试 - 数据克隆及分离：在QA团队对stag环境进行性能测试之前，应对其中的数据进行克隆和分离。

通过以上改进方法，我们可以更好地适应变化，并确保银行系统在AWS云上平稳运行。