据预测，未来 10 年中，企业或组织的数字化转型会达到高峰，将比过去几十年的总和还要多。而这一进程，开发工程师必须找到更加有效的开发方式，才能实现。

在这一层面来说，DevOps 是数字业务转型计划的核心。目前，企业越来越重视DevOps，并开始向这种开发方式转型。但是，如此多声称专注于 DevOps 的企业或组织，真的都做对了吗？

在大多数的 DevOps 实践中，仅仅涉及到了特定工具的使用，企业非常松散地遵循着某些 DevOps 原则。然而，要想真正成为一个以 DevOps 为中心的组织，这些远远不够。参照以下 7 点，或许能够帮助你及时纠偏：

一、部署是完全自动化的

每一个项目工程通常都包含了很多的代码文件、配置文件、第三方文件、图片、样式文件等不同部分，要想将这些部分有效组装、最终形成最后的应用结果，往往需要借助构建工具或策略。

构建过程如果仅仅依赖人工，就会十分繁琐。于是，自动化构建、自动化发布、自动化部署的想法和探索就浮现了。自动化的出现，将大大提升工作效率。

在 DevOps 实践中，是需要从头到尾完全自动化部署的。自动部署的意义不仅仅在于节省时间，更多是避免问题的出现，手动部署更常出现因为人为错误引起的问题，而自动部署可以在问题出现时迅速恢复到以前的版本。

二、有频繁且快速的发布周期

天下武功唯快不破。想要获得更强大的竞争力，只有不断部署和快速修复。DevOps 中一个核心功能就是 CI/CD（持续集成/持续交付），寻找更有效的自动化和部署更新迭代的方法，让开发人员提高生产效率、并快速地发布到生产环境中。

CI/CD 通过在构建、测试和部署应用程序时强制自动化完成。这种 DevOps 方法的精髓在于：

1）通过频繁的代码库提交、自动化构建等来提高生产力；2）通过集成自动化测试以及开发期间的测试，增加在开发早期发现错误的机会；3）得益于频繁的测试和自动化部署系统，可以更快地发布版本。

三、注重可观察性

国外的一份报告显示，可观察性正在成为 DevOps 实践中绝对不能缺少的一环。在跨越多个流程的数字业务转型中，可观察性有非常重要的意义。

New Relic 对 1300 名 IT 领导者、软件工程师和开发人员进行的一项全球调查发现，90% 的受访者认为可观察性对业务至关重要。只有更多地基于事实而非直觉，才能作出明智的决策，越来越多的团队开始从整个企业应用程序环境中收集数据，来提高整个开发过程的可观察性，可观察性也在生产前和生产后的环境中扮演越来越重要的角色。

四、有持续的反馈循环

初期，DevOpsDays 活动的发起人和 DevOps 这个词的创始人 Patrick Debois 发现，有关 DevOps 的话题相互交织在一起形成了四个不同的反馈环，如上图所示。

其中，蓝色气泡代表技术，黄色气泡代表过程管理。一起形成了 4 个循环。开发-测试反馈环（黑色箭头反馈环）；开发-运维反馈环（绿色箭头反馈环）；业务-运维反馈环（红色箭头反馈环）；业务-用户反馈环（紫色箭头反馈环）。

在现在的 DevOps 理念中，出现错误并不可怕，可怕的是没有一个持续的反馈循环系统来检测何时何地出现问题。反馈循环需要在发生错误时快速通知，从而使问题得到更快地解决。

很多时候，我们遇到问题仅仅是简单地解决了它，并没有花时间分析问题发生的原因以及如何防止问题再次出现。这样的循环是不完整的。从某种程度上，如果你设置了一个系统来识别问题、修复问题和改进问题，还需要认真分析，才意味着你在正确地实践 DevOps。

具体来说，一个监控系统需要观察并记录系统状态变化和数据的流程：1）状态的变化：可以通过状态的直接度量或者更新日志来表示；2）数据：可以通过记录内部组件和外部系统之间的请求和响应来记录。

五、开发和运营团队一起工作

Dev（开发） 和 Ops（运维） 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。这个矛盾最先由 John Allspaw 和 Paul Hammond 在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”提出，并以“Cooperation”作为整个演讲的核心，讲述了他们解决这个矛盾的实践经验。

在一个组织中，如果相关利益者的利益不一致，在既定流程的进行中一定会碰到诸多阻力。而在这一点上，首先做的就是把 Dev 和 Ops 的利益一致化，从而减少 Ops 对软件交付的阻力。

在传统观念中，开发的工作是增添新的功能，而运维的工作则是保证站点的稳定和高性能。 而在 DevOps 的观念中，Ops 的工作目标应该是激活业务（enable the business ），与 Dev 是一致的。

至此，DevOps 众所周知的主要好处就是打破开发和运营之间的孤岛。在维基百科上，DevOps 的解释也着重于一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。因此，开发、测试和 IT 运维团队之间的沟通对于 DevOps 的成功至关重要。

六、目标明确

虽然不同团队之间的沟通至关重要，但明确定义每个人都在努力实现的目标同样重要。归根结底，所有团队都有同一个目标：让组织更有效率。

但是，他们为实现这一目标而遵循的个人实践可能会有所不同。团队成员应了解实现目标所需满足的精确要求，而不是做出假设或任其发展。

七、使用正确的工具和平台

DevOps 不仅仅是一种文化转变——它需要强大的工具才能实现。在实践过程中，如果你发现往往需要花费大量时间来解决出现的问题，那么很可能是因为你没有选择正确的 DevOps 工具。

幸运的是，目前的市场上有大量且广泛的 DevOps 工具可以选择，以适应当前现有的所有的数字化基础设施。尽管工具是 DevOps 的重要组成部分，但是要记住，真正使改变发生的是实践。

在众多 DevOps 工具中，近两年来被业内广泛关注的飞算SoFlu因其对软件开发流程的变革而被大量企业应用于DevOps落地，飞算SoFlu是一款管理加开发工具，通过可视化编程的方式满足开发需求。使用平台的一个ID相当于一个10人科技团队，从而使用户有更多精力可以更多关注自身业务。飞算SoFlu中包含的三大核心技术，全都是 DevOps 实践中所要关注的重点：

1）可视化开发

改变传统开发方法，业务逻辑可视化展示，降低开发门槛，无需编写代码，在设计业务逻辑时就形成微服务应用。

2）平台组件

可视化平台组件是一类通用的技术功能模块，平台支持循环条件判断，函数调用，通过拖拽方式以及参数配置实现等同于编写复杂代码的业务逻辑，有别于通过组件排列组合。

3）管理方式

主要通过管理平台来管理需求、研发、测试、部署、上线、运维等整个软件生命周期，经验沉淀、知识积累，将管理制度真正的落地。

截至目前，飞算SoFlu已为包括医疗、金融、制造、零售等在内的八大行业的上百家机构提供了技术服务，助力其落地DevOps，提升研发效率。

一个典型的案例是，飞算SoFlu在某大型国有银行的应用。该银行原本需要3天才能开发完成的接口，使用飞算SoFlu，仅用了5个小时。其IT负责人表示，使用飞算SoFlu后，银行软件中心的整体研发效率获得了大幅提升。

飞算SoFlu的DevOps功能正是在不断的实践中完善升级，从实际业务出发，真正让企业实现降本增效。

交付物

• 软件

100%实现需求明细列表所有功能，即100%满足业务需求的软件。

• 文档

项目验收

• 验收方式

1、将要交付的软件安装于指定服务器，并完成调试和上线；
2、完成培训后，业务验收人员根据需求明细列表实现情况进行验收评价，研发验收人员根据以下内容进行验收评价。

• 文档验收

1、文档齐全（参考如上文档清单）；
2、文档内容描述准确, 没有歧义和错误的表达；
3、文档内容容易理解, 通过使用适当的术语、图形表示、详细的解释来表达；
4、文档对主要功能和关键操作尽量提供应用实例。

• 界面验收

1、界面设计符合自己公司的设计规范；
2、外包团队需提供与软件适配的浏览器、手机、PAD等品牌与版本号清单；
3、各界面需要做好PC、手机、PAD等UI兼容与机器适配；
4、原则上，浏览器至少需适配Chrome、Safari、火狐、IE8以上；
5、原则上，手机至少需适配苹果、小米、华为、vivo、OPPO、三星、魅族。

• 功能验收

1、功能验收范围覆盖（接口、数据库存取、页面功能）；
2、提供单元测试用例、集成测试用例和系统测试用例；
3、提供BUG管理跟踪记录表；
4、提供质量分析报告。

• 性能验收

1、提供性能测试报告；
2、相关重要指标达到以下要求：

• 安全验收

1、软件中的敏感数据需以密文方式存储；
2、软件需有留痕功能，即保存用户的操作日志、系统异常日志、接口调用数据日志等；
3、软件中各种用户的权限分配合理；
4、扫描出的安全漏洞（包含但不限于：越权访问、XSS跨站攻击、SQL注入、文件上传漏洞、跨站请求伪造等）外包团队需修复完毕。

• 用户验收

1、外包团队需提供稳定的用户验收环境和联调环境；
2、业务场景功能测试不通过数的比例<1.5%；
3、不存在严重等级为1的错误；
4、不存在严重等级为2的错误；
5、严重等级为3的错误数量≤5；
6、所有提交的问题都已得到修复；
7、以上功能，用户验收测试通过后，由用户负责人签署验收通过确认书。

源码交接

如涉及到源码交接，按下列规范进行验收和交接。

• 交接前提条件

1、需提供用户验收通过确认书；
2、涉及交接的软件，原则上建议接受交接软件所有功能，不建议交接软件部分功能模块；
3、跟薪资类无关的软件或功能，所有功能需在线上稳定运行不少于3个月；跟薪资类相关的软件或功能，所有功能需在线上稳定运行不少于6个月；
4、线上稳定运行既线上可用率，需满足：最近3至6个月内，线上没有出现影响20人以上或数据错误的严重bug，且每月线上bug数不超过3个。

• 源码验收

1、代码应只保留跟本项目相关的代码，无效代码应一律去除；
2、数据库应只保留跟本项目相关的表、视图、存储过程、函数、触发器、定时job等，无效内容应一律去除；
3、特别注意合理做好数据表结构设计，适当冗余提升性能；
4、代码结构清晰无冗余，注释完整有效，避免硬编码；
5、但凡不符合源码验收规范的，外包团队需修复完毕。

• 其他注意点

1、对于外包团队的软硬件选型，建议业务部门邀请本公司IT团队一起参与决策；
2、与外包团队商签署的商务合同和补充协议等，建议业务部门邀请本公司IT团队一起参与制定；
3、外包团队使用的环境、数据库、网络、语言、框架、技术、组件等需事先获得本公司IT团队认可；
4、如外包项目不符合或无法满足上述验收规范的，建议商务层面延长付款周期、扣除相应款项或终止合同；
5、每一笔合同款在支付给外包团队之前，除了需获得用户验收通过确认书之外，还应通过IT团队验收；
6、以上内容建议附加进商务合同，成为其中一部分。

软件外包存在风险，外包人员技术、态度、交付能力，如果想通过合同或者诉讼降低风险，由于太多的未知因素和太多的主观性，不现实。因此唯一的外包原则应该是：如果外包人员做得不好，有能力随时终止合作且可控费用损失和项目交付。

可以尝试渐进式方法，首先废除传统开发外包大瀑布方式（例如签订需求URS、项目总金额、进度款支付）（不过目前大部分外包会坚持使用瀑布法，并签订大额的预付合同），尝试新方案，项目按照功能或者阶段划分为多个子合同，做小项分包，或者改为签订人力外包合同。

• 针对我们想要构建的功能，拟定一个顺序列表。
• 找几名开发人员，最好是独立的自由职业者，但如果同意以下流程，开发工作室也没问题。
• 对于每名开发人员，挑选列表中最重要的功能，与他们讨论功能需求、预算和成本。
• 让他们实现那个特性并测试。
• 让一名内部人员审核他们的 PR，测试升级后的 App，并标出有问题的地方。
• 符合要求后，合并并部署该特性，这样，所有创始人/用户就可以继续审核该 App，并提供反馈或者根据需要调整。
• 如果我们对他们所做的工作感到满意，就挑选下一个我们希望他们实现的功能，然后再次重复这个过程。
• 如果我们对他们的工作不满意，就解雇他们，并寻找替代者。

当前需要做的工作，整理敏捷开发平台或者公共开发平台，并且参照以下原则：

• 客户合作胜于合同谈判
• 个体和互动胜于流程
• 可运行的软件胜于详细的文档
• 响应变化胜于遵循计划

参考文章：
Experiences working with an Outsourced Dev Shop

我最近发布了个人对Django做为一款优秀应用框架的一些考虑。本文基于此从架构角度做进一步扩展，介绍从开发到生产环境的整体技术栈考虑。

2018 年至今，我一直使用该技术栈构建一些小型 SaaS 应用。

本文最初发布于 www.simplecto.com，经原作者授权，由 InfoQ 翻译并分享。

整体技术栈

随处部署的 Linux 服务器和虚拟机：我使用了 Azure、Digital Ocean 和 Scaleway，并计划在 2021 年将所有部署迁移到Hetzner提供的专用服务器上。

Docker：就是我们常用的 Docker.

Traefik：使用 LetsEncrypt 证书的反向代理和 TLS。

Postgresql：运行在 Docker 中的数据库。

Django：同样运行在容器中。

IntercoolerJS：提供平滑易用的类 Ajax 前端应用支持。Intercooler 的创作者在 2021 年发布了HTMX，是 IntercoolerJS 的更新换代。

Sentry：捕获生产环境中软件缺陷。只需在配置文件中添加几行配置。

Bitbucket Pipelines 替代 CI/CD：鉴于 CI/CD 引入了过多繁琐无用的工具，我在 2021 年不再对个人项目考虑 CI/CD。

ZeroTier：实现 VPN 和控制层。

我在开发小型项目时，采用本地 Docker 容器运行测试，进而直接推送到生产环境。我不考虑使用繁琐的 CI/CD，而是选择了 Bitbucket Pipelines。

上图给出了我所采用技术栈的概览，图中有很多需要详细展开阐述的部分。下面换成列表方式展示。

• 虚拟机
• Docker

• Django

• 挂载数据磁盘卷

• 使用长时间运行 Django 命令做为 Workers

• 挂载数据磁盘卷

• Postgres

• 挂载数据磁盘卷

• Traefik

• Zero-Tier

• SSH

托管环境

即便是无服务器架构，也需要一个云服务托管环境。我个人推荐Azure、Digital Ocean和Scaleway。每家都为计算、联网、存储和基本服务提供了充分的选项，支持用户任何构建需求。

同样推荐Hetzner，它提供了各服务层级的硬件、服务和价格。

虚拟机

一些企业应用和个人副业（side projects），并不需要同时为成千上万的用户提供 TB 级数据服务，因此可扩展性并非主要关注问题。对于此，我们可选用最小托管服务选项，通常不高于每月 20 美元。即便是服务价格相对最贵的 Azure，也可选用 Burstable 服务质量的虚拟机。个人推荐Scaleway的开发层级服务器。

注意：在我的技术栈中并没有 Kubernetes，因为我并未考虑可扩展性。

Docker

为确保新的虚拟机运行在最新版 Docker 上，我并没有依赖操作系统本身，而是使用了 curl|bash 方式，即：

curl -s https://get.docker.com | sudo bash

运行上面一行命令，就能获取最适用于当前运行环境的最新版本。

Traefik 实现反向代理

Traefik 对我简直是天赐之选。尽管 Nginx 也很强大，但其并非针对 Docker 环境构建。Traefik 的两个杀手级特性，为我节省了大量时间：

使用 LetsEncrypt 实现自动 TLS。简而言之，一旦设置，无需操心。结合适用的 API 和 DNS 服务提供商，还可以使用 DNS 验证。

使用 Docker label 实现无需重新加载的自动配置。一旦新服务发布，Traefik 通过监听所有 Docker 相关服务而自动发现更改。这使得服务的添加、移除和合并非常方便，不存在任何麻烦。

我对 Traefik 唯一意见是学习曲线略为陡峭。用户必须自行确定如何进行配置，包括配置文件、命令行选项、YAML、Docker label，乃至组合使用。

提示：我发布了自己使用的Traefik生产环境配置文件，供参考。

Postgres 数据库

亲测推荐，PostgreSQL 从不会令我失望。PostgreSQL 容器可毫无问题地添加到任何项目中。我只需简单地启动容器，绑定端口，挂接数据卷到主机磁盘，仅此足矣。

docker-compose.yml
version: '3.1'


services:


  db:
    container_name: postgres
    hostname: postgres
    image: postgres:11
    restart: always
    environment:
      POSTGRES_PASSWORD: secretsonly
    volumes:
      - ./data:/var/lib/postgresql/data
    ports:
      - 5432:5432
    networks:
      - web


networks:
    web:
        external: tr

用于 Web 的容器化 Django

Django 很好地支持发布到容器中，我多年以来一直这么用。我反复强调开发环境和生产环境匹配的重要性，Docker 为我实现了一切。

我在 2021 年新推出了一个 Django 项目，用做新项目的模板，参见https://github.com/simplecto/django-reference-implementation。

实现异步任务的 Django 命令

我使用做为标准框架组成的自定义Django命令实现异步任务。该模式采用具有 sleep()的 while 循环，轮询数据库相关操作，并采取相应的动作。

截止 2021 年，我已使用这一模式运行一个网站截屏项目一年多，回报丰厚。该项目每日对 1500 个网站做截屏，所有操作由 Django 命令计划和管理。项目地址：https://github.com/simplecto/screenshots。

IntercoolerJS 降低了复杂性

这里如果展开说，需推出多个帖子，恐怕内容太长，以至于不会有人愿意读。我结合 JQuery 和这个小型 JavaScript 库，实现部分类似单页应用的效果，尽管事实上并非单页应用。

IntercoolerJS 保留了 Ajax 的传统优点，从后端 HTML 更新 DOM，无缝且平滑，非常便于实现用户登录和更新小型表单等元素。

强力推荐访问IntercoolerJS官网。

其创立者在 2021 年继承发展了 IntercoolerJS，推出了HTMX。

Sentry 捕获生产中错误

任何应用都会出错，但不应向用户展示。Sentry 提供了一种捕获生产中软件缺陷的易用便捷方式，其特性包括：

开源许可，可在生产中任意部署。

只需在 Django 项目的 settings.py 中添加几行配置，即可生效。

与 Git 代码库和问题追踪系统紧密集成，提供全生产环境的缺陷可追踪能力。

另一个优点是，随时能在生产环境中禁用。

更多信息，可访问Sentry官网。

Bitbucket Pipelines 替代 CI/CD

2021 年，我不在个人项目的部署中使用 CI/CD。其中存在太多工具，复杂性高。我只是使用 PyCharm 运行测试，然后从开发设备直接交付生产环境。

当前存在多种 CI/CD 解决方案，但是我推荐 Bitbucket 提供的 Pipelines 的服务。该服务每月提供数百分钟的免费使用，只需很少费用就能提供自上而下的功能。我自己在使用中很少碰到问题，很喜欢它们的 YAML 配置文件。

我使用 bitbucket-pipelines.yml 文件，实现跨多个 Docker 容器的完全端到端测试，加载数据库，并在几分钟内执行数以百计的测试。该服务是我们团队高效的关键，支持生产环境中每日五次以上 Push。

更多信息，访问Bitbucket官网。

ZeroTier 实现 VPN

最后，推荐一种在很大程度上是可选的、但是最好应具备的技术。Zerotier 是一种独树一帜的网络/VPN 服务，我用其连接所有的个人计算机。它可穿透防火墙联通家庭和办公场所，一分钟即可配置好。

如果所有设备使用 ZeroTier，就可以避免 SSH 中令人头疼的密钥管理，单机上共享带宽。

Zerotier 可运行在 Linux、Mac、Windows、Android 和 iPhone 上，覆盖大部分设备。

ZeroTier 的一个问题在于，我并不完全了解它的工作机制。和 MacOS 和 iPhone 类似，它们会按用户期望工作，并不出问题，只是从用户体验角度看有些不爽。但对于一名 CTO，谁又会去关心具体的细节呢？

总结

希望上面的深入介绍能激发读者对 Docker、Django、Traefik，尤其是 IntercoolerJS 的兴趣。它们简单、易于使用，能在适当时大展身手。

原文链接： Docker, Django, Traefik, and IntercoolerJS is My Go-To Stack for Building a SaaS in 2021
https://www.infoq.cn/article/W4leI4XZ32eSTqFJ8qPl