从两年前就着眼于DevOps目标开始，我们就有了一些可用的初始要素。我们有敏捷的流程，运营团队，自动化工具和可用的技术，但是这些都不是一个引擎。因此，我们开始进行更改。

拒绝改变

改变的不确定性，恐惧和怀疑是人的天性，这创造了拒绝的环境。最困难的任务之一是说服团队实施新的变革，并推动文化转变。

为了解决这个问题，我们从不断的培训，并要求团队慢慢进行这些变更。此过程帮助团队了解了DevOps采用的价值。此外，我们很幸运获得管理团队的支持。没有他们的支持和配合，我们的DevOps变革将是不可能的。

功能交付

我们经历的另一项是功能交付。团队承受着不断的压力，要求他们用很少的时间交付新功能。他们专注于交付工作代码，但不对质量负责。质量是一个单独的质量工程（QE）团队的责任。开发人员日夜工作，提供超出团队能力的代码，但是QE仍然发现很多缺陷。

在进行团队流程调整以采用更改的同时，我们不想发生重大变化来破坏可为客户提供价值的新功能。

那么，我们有什么选择呢？第一步，我们将团队的工作速度降低到其正常工作能力的50％，以确保他们有足够的时间专注于更高质量的工作。其次，我们为团队提供了重新制定和更改“完成”定义的时间，我们开始专注于根本原因分析，并专注于自动化以避免类似的问题和减少将来的问题。
 

2. 凭据管理

项目中会用到大量的凭据，例如数据库、第三方系统对接的 key，使用明文不是一件好事。理想的情况下，对项目中所有的密码信息进行掩盖(mask)，避免 CI、日志中敏感信息的泄露。有很多种方法可以掩盖项目中的密码信息：

• 使用环境变量对密码信息进行覆盖。
• 使用Spring boot 的项目可以配置 jasypt，使用 jasypt 将密码加密，将生成的加密串配置 ENC(加密串) 到工程的配置文件中。加密过程可以加盐作为解密的凭据，“盐” 可以不存放到工程中，在工程部署的时候注入即可。
• 如果使用 Jenkins 等 CI/CD 工具，可以使用构建平台提供的凭证管理工具。
• 如果使用 Spring cloud，可以使用 spring cloud vault 组件部署一个凭证管理服务

另外，建议不要用任何个人凭据用作系统对接，应该使用一个公共的应用凭据。

3. 堡垒机

一般来说我们管理服务器，所有的运维操作需要通过堡垒机进行操作。开放 22 等高危端口，允许开发者直接登录到服务器是一种不安全的做法。堡垒机，通俗的来说是跳板机 + 监控。最初使用的跳板机配置了两张网卡，用于连接开发环境和生产环境，并没有监控功能。在此基础上，堡垒机增加了统一运维管理的功能，往往需要两步验证(SMS 或 Email)，并对所有的操作进行记录和监控。在需要团队参与运维工作的场景中，非常有必要部署一套堡垒机服务，并使用 LDAP 对接到团队成员的 ID 上，便于集中运维管理。

4. 定期对系统软件扫描

Linux 系统往往有云厂商推送安全补丁和风险提示，但是安装到服务器上的软件，例如 JDK、nodejs，需要自己检查安全问题。因此需要在系统中安装并定期运行 CVEs 检查并及时更新。有一款 cvechecker 可以帮助运维人员，编写一个脚本定期运行 cvechecker 检查系统中已知的软件是否存在 CVEs 漏洞，并提醒开发者及时更新。

写在后面

刚开始工作时候，喜欢动态的、灵活的编程语言，讨厌的死板的、套路化的编程语言，然而需要很长一段时间，才能意识到 “约束是程序员的朋友”。对一些安全知识了解的来源大多来自修复 SonarQube 的经历，使用 findbugs 也让我对 Java 基础认识的更加深刻。

类似的，在使用一些框架、平台的时候往往存在大量的限制，有时候开发者难以意识到 “限制” 正是框架、平台的作者 “保护” 应用开发者的一种方式。有一些开发者以 Hack 框架、平台为乐，但是这样会带来潜在的隐患，在用户量上来之后负面效应表现的尤为明显。

项目的规范化对于 Tech Lead来说可以减少程序的运行事故和 codereview 时间，对于团队来说也许可以少加班吧。

（编辑：柳州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!