• DevOps



    特别说明

    本文是已读书籍的学习笔记和内容摘要,原文内容有少部分改动,并添加一些相关信息,但总体不影响原文表达。
    《DevOps入门与实践》 :本书结合实例详细介绍了在开发现场引入DevOps的具体流程。

    个人简评

    适合已有实践经验的实施人员,对已有知识和技能做结构性梳理。
    适合对DevOps欠缺了解的人员,能够建立起基本的概念。
    但由于外文书籍翻译引入与中文出版存在时间差,导致书中涉及的一些工具和方法,落后于当前主流应用场景。


    1 - DevOps的含义

    DevOps涉及领域广泛,其含义因人而异,在不同的理解和需求场景下,有着不同的实践形式。
    DevOps可以理解为是一个职位、一套工具集合、一组过程与方法、一种组织形式与文化。
    但从商业价值角度来说,DevOps是指通过Dev(开发)和Ops(运维)的紧密合作来实现和提高商业价值的工作方式和文化。
    不仅包括了新技术和新工具的使用,还包括相关的团队组织建设和文化,实现持续改善的运维结构,以及开发流程设计等。
    通过开发与运维之间的协作,能够消除对个人的依赖、减轻团队之间的损耗,提高质量和开发速度,并通过互相理解来增强变更的灵活性,快速满足商业需求。

    各种支撑DevOps的思想、改善对策和工具共同组成了DevOps,难以在广泛的场景中明确地指出DevOps实践的准确定义。
    但通常都会包括实现“基础设施即代码”和组建适合DevOps的体制这两部分。

    “基础设施即代码”是在DevOps实践中支持开发和运维紧密合作的一个非常有效的方法。
    “基础设施即代码”,可以简单理解为:

    • 将服务器、网络设备等基础设施的设置和架构代码化、信息化,把软件开发的开发模式应用到基础设施运维中。
    • 所有基础设施的构建、变更都根据其配置信息来进行,所有成员都可以访问配置信息,对配置信息的更改也都如实地反应在基础设置环境中。
    • 按照定义文件的要求来编写和更改配置信息,使用测试工具对其进行测试,并将配置信息和代码一样进行版本管理。

    组建适合DevOps的体制,运维团队和开发团队共享信息,在变更时互相审查,深入了解对方的工作内容,进而理解并达成共识。
    拥有共同的目的意识,双方通过自主行动来不断接近共同目标。

    此外,DevOps是融合在业务中的持续性的改善和实践,而不是为了一次性完成所有的改善。

    2 - DevOps的诞生与要素

    2.1 两个关键因素

    理解传统开发模式和敏捷开发模式的不同,以及各自的问题。

    以敏捷开发为代表的持续开发方式的出现

    瀑布模型明确划分了开发阶段和各阶段的产出物,无法有效应对新增需求。
    敏捷开发以小规模团队为前提,每次只发布最低限度的功能集,然后听取反馈,进行持续改善。

    持续开发带来的运维问题

    开发和运维之间的产生“混乱”:运维产生技术负债、抵触变更和基础设施不足,开发忽略非功能性需求,运维和开发逐渐“割裂和对立”。

    2.2 应对变化

    开发部门确保需求的实现,运维部门确保系统稳定、快速地运行,但最重要的根本任务是确保商业的有效性,商业价值的实现
    通过工具和文化来支持开发和运维紧密合作,消除专业性和复杂性,减少工作量,同时使信息可视化,以此来降低变更带来的风险。
    团队中任何成员都可以基于相同的信息迅速开展工作,同时通过自动化和持续集成来大幅缩短应对变更所需要的时间,高效满足商业需求。

    工具所具备的要素

    • 抽象化:通过“标准化”或“虚拟化”来抽象化所有资源,消除不同平台之间的差异,降低专业难度和复杂度
    • 自动化:通过自动化方式使用抽象化的资源,降低专业难度,减少开发、运维人员的工作压力
    • 统一管理:通过统一的版本管理系统和沟通工具使信息可视化,构建开发和运维之间的紧密联系,进行有效的信息传播和沟通
    • 即时沟通:通过互联网通讯工具和聊天机器人,加强点对点的联系和减少对敏感信息的反应时间
    • 持续集成与部署:统一开发部门和运维部门的开发及构建方法,一步式构建和部署,大幅提升系统改善的速度
    • 监控:对资源等信息进行集中管理和可视化,构建开发和运维的紧密合作关系

    文化所具备的要素

    文化的含义:尊重(Respect)、信任(Trust)、正确认识失败(Healthy attitude about failure)和避免指责(Avoiding Blame)。

    • 目的意识:相同的目标,共同创造服务、迅速满足商业需求,更容易实现紧密合作。
    • 同理心:互相考虑对方的感受,接受对方,建立紧密的关系
    • 自主思考:不互相依赖,能自主开展工作,以此来不断接近共同目标

    3 - DevOps的工具应用

    3.1 抽象化

    • 操作系统:使用LXC(Linux Containers)实现的容器技术Docker
    • 物理服务器:虚拟机,在虚拟机上混合型部署和运行容器
    • 存储:根据SDS(Software Defined Storage)思想用软件和API来对虚拟化存储进行控制
    • 网络:VLAN(Virtual Local Area Network)、SDN(Software Defined Network)

    3.2 自动化

    基于REST API可以根据指定的参数来进行自动化配置。
    REST API可以用URL表示资源,通过HTTP协议来获取资源的状态或者变更资源的配置。

    3.3 统一管理

    在设计上支持和外部系统进行集成,可以将更新信息发送到外部沟通工具,也可以直接共享URL来访问指定的信息。

    • 问题跟踪系统(Issue Tracking System, ITS):也被称为Ticket管理工具,例如JIRA、Redmine等
    • Wiki:保存设计文档和会议记录,例如Confluence和Redmine的Wiki

    3.4 即时沟通

    例如通用的WeChat、Skype等,面向企业的Cisco Jabber、Chatwork等。
    将聊天机器人与聊天工具、业务系统集成,可以代替部分的人工作业,提升反应速度。

    3.5 持续集成与部署

    除了开源的持续集成和部署工具Jenkins,还有云的持续集成工具服务,例如Circle CI和Travis CI。
    在持续交付阶段,可采用蓝绿部署方法来确保部署的安全性。

    3.6 监控

    主流的监控工具主要是指Zabbix。

    • 实时把握资源的使用状态和业务的运行状态
    • 获取和分析商业活动所需的数据,进行持续改善
    • 指标监控,对关键指标进行定量分析和优化

    3.7 日志分析

    通过组合不同的中间件,可以将日志作为监控信息来进行分析处理。

    • 用于日志收集:Logstas
    • 从收集的日志中检索过滤信息:Elasticsearch
    • 将结果可视化:Kibana
      以上三个中间件统称为ELK栈,是被广泛使用的主流组合。
  • 相关阅读:
    Kruskal
    克鲁斯卡尔
    克鲁斯卡尔
    实践是检验真理的唯一标准 脱壳篇02
    Kruskal
    克鲁斯卡尔算法讲解
    实践是检验真理的唯一标准 脱壳篇02
    最小生成树(普里姆算法) 数据结构和算法62
    克鲁斯卡尔算法讲解
    最小生成树(普里姆算法) 数据结构和算法62
  • 原文地址:https://www.cnblogs.com/anliven/p/11823793.html
Copyright © 2020-2023  润新知