我们的团队在公司成立之前就已经开始应用DevOps实践，而我个人，早在十年前，在另一家公司担任系统管理员时，我首先接触到了这种新鲜的思维方式。当时还没有DevOps这个标准名词，但当时实践的人也自己摸索了一些相关的概念和原理。持续集成;自动交付；每个团队成员都对产品负责；与客户直接沟通；业务/应用程序指标的收集和分析；逻辑扩展，以及这些方法的滋生地，是开发者不再简单地为本地主机编写代码的基本前提。Atlassian提出的DevOps原则Atlassian提出的DevOps模型在今天仍然非常重要。从本质上讲，它代表了产品开发和交付的现代周期，涵盖了产品发布后的运营流程。1、前DevOps时代：管理员和开发者的鸿沟长期以来，产品的运营和开发是分离的。这条鸿沟的一端是勤劳踏实的开发人员，另一端是开发人员眼中行尸走肉般的系统管理员。系统管理员不参与开发，他们不与开发团队沟通，他们通常只是获取代码包并尝试在某个地方运行它。每次运行尝试都非常痛苦，管理员花费数天时间仔细研究日志、寻找无法理解的错误、分析数据库查询、陷入无休止的strace过程等。在许多情况下，事实证明，只需定义即可解决问题一个新的环境变量或添加一个新的参数。但不幸的是，开发人员永远没有机会将情况告知管理员，而后者唯一知道的就是产品的名称和用什么语言编写的……2.十年前的“DevOps”工作多年前，我刚开始在团队中担任管理员。当时公司的思路比较灵活。我并没有像《IT 狂人》的剧情那样被安排在地下室的小黑屋里，而是在开发者中有自己的。桌子。从那一刻起，我也踏上了自己作为DevOps工程师的旅程。在公司工作后，我很快意识到，虽然知识和技能很重要，但从沟通和运营角度看待和影响产品的能力更值得关注。我有权不同意，表达我的顾虑，并在最终交付前很久就向开发者传达我的意见或提醒他们调整写作方式。这才是真正的管理者，不应该被“囚禁”在地下室！事实很快证明，对产品的设计、开发和运营等要素进行综合考查，确实可以带来巨大的收益。只有当每个人都对产品负责，清楚地了解产品在生产中将如何运行时，开发过程才能真正融入生产过程。所有这些今天人们习以为常的想法，在当时无非是一种文化冲击——开发者和管理者真正携手，天下无难事！而这一切，都无法通过被通信鸿沟严重隔开的传统流程来实现。但是，如果DevOps只是一个引入了开发阶段概念的敏捷开发过程，那么DevOps工程师是做什么的呢？DevOps世界中的核心职责到底是什么？这就引出了另一个重要问题：谁应该是DevOps团队的理想领导者？团队领导角色可以由没有特定职位或背景的中级专业人员担任（可以是开发人员、管理员，甚至是QA）。DevOps的主要目的是填补产品持续集成、交付和运行周期中的空白。从个人主观上来说，我觉得DevOpsleader最好有管理员背景（而不是选择所谓的“技术骨干”）。由此，他/她可以隔离与数据库升级、配置管理或任何其他让开发人员分心或烦恼的底层基础设施相关因素。在这里，我还想说明一点，管理员更适合担任DevOps领导：随着产品的发展和成熟，DevOps团队也会扩大，因此需要的时间和精力也会相应增加。如果您指定一名开发人员领导您的DevOps团队，他或她将很难专注于开发。最后一个原因：管理员更容易开始使用DevOps，因此上手速度更快一些。3.DevOps工程师应该知道什么？DevOps工程师应该了解和做什么？本文为DevOps工程师整理了一份技能清单。当然，这个列表可能并不完整，它只涵盖了工程师应该具备的一些核心技能。敏捷开发原则这也是现代开发世界（尤其是远程协作开发场景）中最重要的技能之一。这不仅包括区分看板和Scrum的区别，还要求我们能够与团队顺畅沟通，理解客户价值，及时跟踪进度，组织理解工作日志、独立报告和清晰文档的能力。自动化+一切都是代码每个人都应该尽快摆脱手工操作的困扰。今天，几乎每天的工作都对应一个自动化工具。如果找不到现成的工具，您也可以使用Python和bash编写自己的工具。例如，如果您需要创建虚拟机映像，请使用Packer。如果需要配置超过10台主机，请使用Ansible。如果您在GoogleCloudPlatform中创建Kubernetes集群，或者需要在Amazon上使用CDN，请使用Terraform来简化流程。总而言之，从通过网络加载新的裸机服务器到在现有集群中部署新容器，一切都应该以自动化方式进行。另外，你写的代码应该是可复现和幂等的，提交的内容必须经过跟踪程序的审核，并严格遵守以上要求。云和混合架构目前，我们发现大多数企业并没有只使用一家云服务提供商（以避免供应商锁定问题）。没错，一切都不应该简单粗暴地交给云解决方案。我们可以在AWS、Heroku和其他IaaS、PaaS和SaaS上运行服务的不同部分。请尽量寻找最理想的解决方案，并确保在一定时间内完成不同平台之间的服务迁移。另外，别忘了前面提到的自动化原理。自动化程度越高，迁移难度越低。可伸缩性和高可用性要求的最重要方面是了解企业在给定时间段内可以容忍多少停机时间和数据丢失。一旦弄清楚这一点，就会清楚假设资源停机时间长达24小时是没有意义的。此外，即使一个资源只宕机一个小时，其损失也可能比使用全热备份服务一整年的成本还要高。借助云服务和容器化技术，系统的规模扩展变得更加容易。然而，基础设施和服务本身也需要为这种灵活的可扩展性做好准备（再次攻击本地对象存储，这简直就是麻烦的最终来源）。监控与告警为了及时审查、预测和响应，当然需要收集系统、应用和业务中所有可用的指标。这些指标就像团队的眼睛，无法通过单一的监控解决方案完全实现。每个云服务或平台都提供自己的一组可用指标和警报，但您还需要使用外部系统，例如Librato或Datadog，或者根据您的需要在Prometheus之上构建自定义监控服务。总之，所有的选择都应该基于合理的预算、时间和任务要求。安全安全保障确实不是DevOps工程师的核心职责。但是，每个人都必须掌握相关的安全基础知识。端点部署SSL，策略中没有*，没有公共或可写的存储桶，分区需要加密，注意部署封闭的防火墙、安全组、多因素认证等。另外，DevOps还应该与安全部门合作，在自动化流程的同时快速将新的安全策略应用于服务。4、DevOps工程师的角色不需要DevOps工程师，太阳好像照常升起……如果整个业务系统都配置好，运行正常，为什么还需要DevOps专家？没错，已经有相当多的开发者搭建了一个完整的环境，包括功能完善的数据库，甚至还有一个自动伸缩组。当然，更现实的情况应该是他们已经在Heroku上推出了相关的应用，添加了必要的插件，告警和监控指标也已经轻松实现了，一切看起来都无望了。在这种情况下，还需要解决以下问题。所有操作通常只能手动完成，如果您的云服务提供商出现问题，您将无法复制模式或部分恢复模式。由于缺乏对资源消耗的有效控制，该方案的运行成本较高。配置后，许多服务可能根本无法使用，但仍会向您收费。一般来说，快速发布是开发过程的重中之重，但同时缺乏必要的优惠选项和替代方案等成本调整空间。此外，这些解决方案大多没有充分发挥预留实例的成本优势。部署过程并不完美。由于缺乏统一的测试手段，集成测试往往只是一句空话。大多数正在运行的测试只能由开发人员在本地执行。某些奇怪的错误只出现在生产中，但无法在本地重现。这会影响客户对IT部门的信任，最终IT部门和项目负责人会成为不共戴天的敌人。有时会出现性能问题，但原因并不总是很清楚。单点故障无处不在，解决和修复非常耗时，进一步拖慢了本已缓慢的开发过程。需要将您的服务迁移到另一个平台，并为快速增长的业务做架构准备。监控警报来不及采取行动。开发团队很可能是最后一个发现问题的团队。在最极端的情况下，即使用户和客户大发雷霆，开发团队也会被蒙在鼓里。这个列表当然不完整，我们还可以补充更多的问题，有些问题可以通过及时沟通解决，有些问题需要配合交付和开发流程的优化。但要完成这些优化，需要探索纯技术技能或特定平台相关知识，本文暂不讨论。
