在当前的 IT 实践中，为了支持高效和快捷的软件开发，出现了巨大的转变：在单体应用的软件架构正在逐渐被微服务架构取代的情况下，开发、 QA 和运维团队为了摆脱了之前相互孤立的状况，开始相互关联并融合统一，我们将其称为DevOps。
当今如果一个技术驱动型企业想要以客户为导向来进行快速的软件迭代，那么他们需要更快速的软件开发和交付周期。而这些需求直接导致了 DevOps 文化的核心 CI/CD 实践的诞生。
CI 持续集成：一种专注于使发布更容易的软件开发实践。
CD 持续交付：是持续集成的延伸，以确保您可以以可持续的方式快速向客户发布新的更改。
那么让我们试着了解什么是 DevOps ？
Atlassian 将 DevOps 定义为：DevOps 是一组软件开发和运维团队之间的自动化流程实践，以便他们可以快速、可靠地构建，测试和发布软件。DevOps 的概念建立在为过去相对孤立的团队之间建立合作文化的基础上。其带来的好处包括更加可靠、更快的软件发布，快速解决关键问题的能力，以及更好地管理计划外的工作。Amazon 将 DevOps 定义为：文化理念、实践和工具的结合，提高了团队的高速交付应用程序和服务的能力：与使用单体应用的软件开发架构管理流程的团队相比，以更快的速度开发和改进产品。这种速度使团队能够更好地为客户服务，并在市场竞争中占据有利地位。Microsoft 以更简化的方式定义 DevOps：DevOps 可以为我们的终端客户持续提供价值的人员，流程和产品的结合。我认为 DevOps 的最佳解释为：它是一种文化，是一种将人放在首位团队理念，为他们提供适宜的环境，使他们能够蓬勃发展，因此无论他们属于什么部门，都可以通过明确的流程进行协作和沟通，从而实现目标。
因此，开发人员，QA 和运维团队使用 CI/CD 实践来实现客户的预期目标。开发人员编写代码并将其提交到 GitHub 等源码控制工具。DevOps 工程师使用 CI 工具来提取代码，来进行自动化测试，并通过 CD 工具部署到处理生产或测试服务器。
开发和运维人员一起工作，并使用各种工具进行 CI/CD 和监控，以快速响应客户需求并修复问题和错误。
DevOps 工程师可以使用多种工具在整个 DevOps 生命周期的每个阶段获取期望的结果。
计划
您可以使用 Jira 或 Azure DevOps Board 以敏捷方式管理和规划您的工作。
开发
对于代码管理， Git 以分布式方式管理代码版本历史、分支、推送和拉取机制的首要工具。您还可以使用 Microsoft TFVC（Team Foundation Version Control），这是一个集中版本控制系统。
测试
要进行自动化测试，您可以使用 Selenium 、 JUnit 和 Apache JMeter 。
集成
Jenkins 是目前最受欢迎的 CI 工具之一，它可以做到无缝地集成开发和运维流程。
其他 CI 工具还有 Travis ＆ Bamboo。
部署和配置管理
Docker 是最受欢迎和广泛使用的持续部署工具之一。它也是软件容器化工具。
其他部署和配置管理工具还有 Kubernetes 、 Chef 、Ansible 和 Puppet。
Kubernetes 是一个开源容器管理（编排）工具。其容器管理职责包括容器部署，容器扩展和伸缩以及容器的负载均衡。 （如果你想深入快速学习Kubernetes， 可以报名参加我们组织的为期3天的Kubernetes实战培训，一线资深讲师带你从0开始上手Kubernetes。）
监控
将产品部署到正确的位置后，持续的监控就变得至关重要。 Nagios、 Splunk 和 New Relics 是广泛使用的持续监控工具。
持续集成
持续交付
微服务
基础设施即代码
监控和日志
沟通与协作
让我简要解释一下：
持续集成
Amazon 将 CI 定义为：
DevOps 软件开发实践，开发人员定期将代码修改合并到中央存储库，然后运行自动构建和测试。持续集成通常是指软件发布过程的构建或集成阶段，并且需要自动化组件（例如，CI 或构建服务）。持续集成的目的是更快地发现和解决问题，提高软件质量，并减少验证和发布新软件更新所需的时间。
持续交付
持续交付是一种软件开发实践，其中开发人员完成的任何代码更改都会自动为发布到生产环境做好准备。
通过在构建阶段之后将所有的代码更改部署到测试环境或生产环境，持续交付可在持续集成时进行扩展。
微服务：敏捷开发的架构
这是一种新的软件设计方法，您可以将单个应用程序拆分为一组小型服务/模块。与单体应用架构将所有前端和后端代码库以及数据库都全部部署在同一个服务器地址中相比，基于微服务架构的应用程序被分解为服务，其中每个服务器都在其中运行使用基于 HTTP 的应用程序编程接口（API），通过定义良好的接口使自己与其他服务进行通信。
按照 Amazon 的介绍：
微服务是围绕业务能力构建的; 每项服务的范围都是一个简单的用途。您可以使用不同的框架或编程语言来编写微服务并将它们作为单个服务或一组服务独立部署。
基础设施即代码：IaC
是通过机器可读定义文件（代码库）管理和配置计算机数据中心的过程，而不是物理硬件配置或交互式配置工具。
Amazon 定义 IaC 为：
作为使用代码和软件开发技术（例如版本控制和持续集成）来配置和管理基础架构的实践。云服务的 API 驱动模型使开发人员和系统管理员能够以编程方式大规模地与基础架构交互，而不需要手动设置和配置资源。
因此，开发人员可以使用基于代码的工具与基础架构进行交互，使其更像应用程序。这使得可以使用标准化模式快速部署基础架构和服务器，使用最新的补丁和版本进行更新，或以副本的方式进行复制部署。
传统的服务（生命周期）自动化和配置管理工具用于完成IaC。现在企业也在使用连续配置自动化工具或独立的 IaC 框架，例如 Microsoft 的 PowerShell DSC 或 AWS CloudFormation。
监控与日志
公司可以通过监控指标和日志，来了解其应用程序和基础架构的运行情况。APM（Application performance management 应用程序性能管理）将 IT 指标转换为有意义的业务指标，致力于检测和诊断复杂的应用程序性能问题，以维持预期的服务等级。
通过捕获、分类、分析应用程序和基础架构生成的数据和日志，团队可以了解更新是如何影响用户的，从而深入了解问题或报错的根本原因。
wiki 中介绍：
密切监控两组性能指标。第一组性能指标定义了应用程序终端用户所体验的性能。性能的一个示例是峰值负载下的平均响应时间，包括加载和响应时间。
负载是应用程序处理的事务量，例如，每秒事务数（tps）、每秒请求数、每秒页数。在没有被计算机的搜索、计算、传输等需求加载的情况下，大多数应用程序都足够快，这就是开发人员在开发过程中可能无法捕获性能问题的原因。
响应时间是应用程序在此类负载下响应用户操作所需的时间。
在我看来：
团队中的 DevOps 作为一种实践取得成功，需要2个基本支柱：沟通和协作，才能非常有效地工作。如果没有这种感觉并理解紧密结合团队工作的重要性，那么采用 DevOps 最佳实践将非常困难。
增加团队中的沟通和协作是 DevOps文化 的关键方面之一。有了这种文化，团队就会以良好的态度和动力聚集在一起，围绕信息共享建立强有力的文化规范，并通过沟通工具和应用促进沟通，使团队的所有部门能够更加紧密地协调共同的目标。
让我们看看由 veritis 带给您的以下信息图表。
以上给出的图表清楚地阐述了 DevOps 实践的主要好处：
速度
DevOps 促进团队的高速开发，以便您可以更快地为客户进行创新，更好地适应不断变化的市场，并在推动业务成果方面提高效率。
快速交付
通过基于 CI/CD 的 DevOps 文化，缩短了应用程序发布周期，允许更快的客户反馈和有意义的创新在团队内的蓬勃发展。您可以更快地发布新功能并修复错误，更快地响应客户的需求并建立竞争优势。
可靠性
DevOps 使您能够通过持续集成和持续交付等实践不断提高您的软件质量，以测试每项变更的功能和安全性。这造就了可靠和经过测试的应用程序和强大的基础设施的开发。DevOps 持续监控和记录实践可以帮助您实时了解软件的性能。
文化
DevOps 培养了一种伟大的工作文化，在其文化模式下建立更有效的团队，强调所有权和责任等价值观。
安全
通过采用 DevOps 模型，组织可以使用基础架即代码和策略即代码，在不牺牲安全性的情况下大规模定义和跟踪合规性。他们可以在保持控制和合规性的同时快速进步。
“当你试图在团队中带来任何相当大的变化时，一开始可能看起来很难，但当你有足够大的意愿时，就会发生变化，并渐进达成目标。”
因此，让我们看看采用 DevOps 作为文化的一些常见挑战。
Dev Vs Ops 心态
由于长期的开发和运维团队一直在孤立地工作，完成不同的任务。所以他们经过精心调整，以不同的方式思考和行动。开发人员试图尽快创新并做出改变，运维人员则试图保持 100％ 的服务可用性。他们的目标和优先事项是不同的，所以如果我们必须将 DevOps 作为团队中的文化实践，那么如果他们的心态还是两个孤立的部分，那么 DevOps 必将黯然失色。
DevOps 的实践就是将团队整合在一起，打破 IT 组织内部的孤岛。因此，将它们整合为统一单元以实现共同目标是任何公司在采用 DevOps 实践时需要克服的第一个障碍。
从传统基础设施转向微服务架构
多年来，这些公司一直存在遗留的基础设施，但如果他们必须快速创新，他们必须摆脱这种方法并采用更具可扩展性的微服务架构。将基础设施即代码与微服务一起使用是迈向持续创新未来的又一步。
然而，将架构变为微服务架构系统存在很大的障碍。采用微服务架构需要采用最佳的 DevOps 实践以及 CI/CD 实践。这为团队带来了巨大的工作量和运维挑战，同时也增加了成本因素。
确实，将开发与部署转变为现代的软件开发方案可能会很痛苦，但一旦采用就可以使您的团队变得更加高效与可扩展。
开发和运维工具集的冲突
开发团队的目标和指标完全不同，因此他们可能需要一个运维团队可能不需要的工具集。因此，必须将两个团队聚集在一起，以了解他们两者可以合作的位置，并整合对他们两者都有意义的工具，并统一他们可以监控的目标和指标。
一些团队可能不愿意使用传统工具，这些工具不仅技术上较差，而且由于兼容性问题也会降低整个基础架构的速度。因此，请确保正在使用的工具与公司的产品愿景保持一致。
原文链接：https://medium.com/faun/all-about-devops-fundamentalsyou-ever-wanted-to-know-2333328a2b40
扫一扫
1755
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
