运维建设之理论基础

导读

本文主要介绍运维建设依赖的理论基础,并结合工作实际给出了一些分析。

DevOps

DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会,为了在Twitter上更方便的传播,由DevOpsDays缩写为DevOps。

DevOps是一组过程、方法与系统的统称,用于促进开发、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的目标是缩短从开发到部署的周期,通过打破开发、测试、运维之间的壁垒,实现持续交付(Continuous Delivery)。

DevOps落地依赖组织文化(Culture)、自动化(Automation),同时也要关注结果度量(Measurement)、知识分享(Sharing),所谓的CAMS四原则。CICD等自动化技术只是其中一个环节,并非全部。

效果方面,相比于软件开发的瀑布模式、敏捷开发,DevOps将开发、测试、部署三个环节打通,做到了快速迭代、持续反馈;其价值,不再限于开发阶段、而是贯穿了软件全生命周期。

zone

zone

当前盛行的云原生概念,吸纳和演进了DevOps理念,云原生技术促进了DevOps的结果达成。

本文主要内容,引用自鲜枣课堂的《DevOps到底是什么意思》

GitOps

GitOps最早由Weaveworks公司在2017年提出,是IaC在K8S生态下的一种实现,也是对DevOps理念的一次实践落地。GitOps具备声明式基础设施、版本化、自动化等特征,做到了配置变更可审计、可重复、一致性,完全符合IaC定义。同时GitOps又超出了常规的IaC能力,因为它使用Git做代码管理,并最大限度的复用了Git的工具生态。一个典型的GitOps实现如下图,

zone

GitOps将应用的所有环境配置都通过Git进行管理,并通过自动化的流程进行交付和变更,这样就是GitOps的核心理念。具体的,

GitOps代码分为应用仓库、环境仓库两部分。应用仓库保存应用源码、应用部署描述等信息,对应上图中的Image Registry。环境仓库则描述了某部署环境(如生产环境、测试环境)的构成,包括应用列表、基础服务列表、对应的配置和版本等,对应上图中的Environment Repository。

GitOps操作定义了一个完全自动化的控制器Operator,该控制器负责观察、对比真实部署环境的状态(基线是环境仓库的描述),并确保两者达成一致。

参考文献:GitOps

FinOps

FinOps基金会(F2)成立于2019年02月,于2022年06月并入Linux基金会(LF)。F2起源于Cloudability的客户顾问委员会会议(Cloudability’s quarterly Customer Advisory Board meeting),在这个会上众多从业者呼吁成立一个独立于云厂商的社区、一起讨论云成本的最佳实践。Cloudability一家云服务成本管理平台。当前,F2的技术咨询委员会阵容并不是太强大。

云服务模型

通常有三种云服务模型:SaaS(软件即服务),PaaS(平台即服务)和IaaS(基础架构即服务)。

zone

SaaS代表了云市场中企业最常用的选项。SaaS利用互联网向其用户提供应用程序,这些应用程序由第三方供应商管理。大多数SaaS应用程序直接通过Web浏览器运行,不需要在客户端进行任何下载或安装。由于其网络传输模式,SaaS无需在每台计算机上下载和安装应用程序,而在每台计算机上下载和安装应用程序正是IT员工的噩梦。通过SaaS,供应商可以管理所有潜在的技术问题,例如数据、中间件,服务器和存储,因此企业可以简化其维护和支持。典型的SaaS包括Google Apps、Dropbox、Salesforce、Cisco WebEx、Concur和GoToMeeting等。

PaaS为某些软件提供云组件,这些组件主要用于应用程序。PaaS为开发人员提供了一个框架,使他们可以基于它创建自定义应用程序。所有服务器,存储和网络都可以由企业或第三方提供商进行管理,而开发人员可以负责应用程序的管理。PaaS的交付模式类似于SaaS,除了通过互联网提供软件,PaaS提供了一个软件创建平台。该平台通过Web提供,使开发人员可以自由地专注于创建软件,同时不必担心操作系统、软件更新,存储或基础架构。PaaS允许企业使用特殊的软件组件设计和创建内置于PaaS中的应用程序。由于具有某些云特性,这些应用程序或中间件具有可扩展性和高可用性。典型的PaaS包括AWS Elastic Beanstalk、Windows Azure、Heroku、Force.com、Google App Engine,Apache Stratos,OpenShift。

IaaS由高度可扩展和自动化的计算资源组成。IaaS是完全自助服务,用于访问和监控计算、网络,存储和其他服务等内容,它允许企业按需求和需要购买资源,而不必购买全部硬件。IaaS通过虚拟化技术为组织提供云计算基础架构,包括服务器、网络,操作系统和存储等。这些云服务器通常通过仪表盘或API提供给客户端,IaaS客户端可以完全控制整个基础架构。 IaaS提供与传统数据中心相同的技术和功能,而无需对其进行物理上的维护或管理。IaaS客户端仍然可以直接访问其服务器和存储,但它们都通过云中的“虚拟数据中心”。与SaaS或PaaS相反,IaaS客户端负责管理应用程序、运行时、操作系统,中间件和数据等方面。但是,IaaS的提供商管理服务器、硬盘驱动器、网络,虚拟化和存储。一些提供商甚至在虚拟化层之外提供更多服务,例如数据库或消息队列。典型的IaaS包括DigitalOcean,Linode,Rackspace,AWS,Cisco Metapod,Microsoft Azure,Google Compute Engine(GCE)等。

本文主要内容,引用自《一张图看懂IaaS、PaaS和SaaS的区别》

技术成熟度曲线

Gartner技术成熟度曲线(Gartner’s Hype Cycles),以图形方式展示了技术和应用的成熟度和采用情况,以及它们与解决实际业务问题和利用新机会的潜在相关性,Gartner原文

multicloud-architecture

每个技术成熟度曲线,都将新技术的生命周期划分为如下五个关键阶段,

  • 技术萌芽期:潜在的技术突破即将开始。早期的概念验证报道和媒体关注引发广泛宣传,通常不存在可用的产品、商业可行性未得到证明
  • 期望膨胀期:早期宣传产生了许多成功案例,通常也伴随着多次失败。某些公司会采取行动,但大多数不会
  • 泡沫破裂谷底期:随着实验和实施失败,人们的兴趣逐渐减弱,技术创造者被抛弃或失败。只有幸存的提供商改进产品,使早期采用者满意,投资才会继续
  • 稳步爬升复苏期:有关该技术如何使企业受益的更多实例开始具体化,并获得更广泛的认识。技术提供商推出第二代和第三代产品,更多企业投资试验,保守的公司依然很谨慎
  • 生产成熟期:主流采用开始激增。评估提供商生存能力的标准更加明确,该技术的广泛市场适用性和相关性明显得到回报

技术成熟度曲线在运维领域同样适用,如辅助判断云原生的成长阶段、决定运维大规模投入的时机。

康威定律

康威定律(Conway’s Law)可以简述为: 「组织结构决定产品形态」,想要什么样的系统、就搭建什么样的团队,有什么样的团队、就尝试搭建什么样的系统。

康威定律,是马尔文-康威1967年提出的,起初发表在杂志上,后经《人月神话》引用而出名、并被命名为康威定律。康威定律包括四个定律,

  • 第一定律: 组织沟通方式决定系统设计
    • 原文: Communication dictates design
    • 举例: 想要搞微服务,公司的团队就要按照微服务来划分。想要什么样的系统,就搭建什么样的团队;有什么样的团队,就尝试搭建什么样的系统、不要无畏挣扎,如小公司团队没得划分、搞微服务就是找死
  • 第二定律: 时间再多一件事情也不可能做的完美,但总有时间把他做完
    • 原文: There is never enough time to do something right, but there is always enough time to do it over
    • 举例: 人手永远是不够用的,事情也永远做不完,但可以一件一件的来。这也是Devops要解决的问题,即持续的开发、测试、交付、部署,过程中不断反馈调整
  • 第三定律: 线型系统和线型组织架构间有潜在的异质同态特性,这是第一定律的具体应用
    • 原文: There is a homomorphism from the linear graph of a system to the linear graph of its design organization
  • 第四定律: 大组织比小系统更倾向于分解
    • 原文: The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
    • 举例: 组织沟通成本随着人员数量指数增长,沟通成本=Nx(N-1)/2,这也是为什么互联网公司往往追求小团队

从康威定律可以看出,技术架构绝不仅仅是一个技术问题,更是公司组织和政治问题、公司越大越是如此。参考了原文

墨菲定律

墨菲定律指的是:如果坏事情有可能发生,那么它一定会发生,只要事情的重复次数足够多。墨菲定律,由美国空军上尉工程师爱德华·墨菲(Edward A. Murphy)1949年提出。

数学依据:假设某事件在一次实验(活动)中发生的概率为p(p>0),则在n次实验(活动)中至少有一次发生的概率为P=1-(1-p)n。由此可见,当实验次数n趋向于无穷时、P会越来越趋于1,即成为必然事件。

结合运维领域,不要轻易漏掉小概率隐患,不要相信小概率事件、该发生的一定会发生。

海恩法则

海恩法则指的是:每1次严重事故的背后,必然有29次轻微事故、300次未遂事故、1000个事故隐患。海恩法则(Hain’s Law),是德国飞机涡轮机的发明者帕布斯·海恩提出的、航空飞行安全法则。

海恩法则强调,任何事故都是可以预防的。关键点,一是量变引起质变、严重事故是隐患累积的结果;二是再好的技术、再完美的规章,在实际操作层面也无法取代人自身的素质和责任心。

结合运维领域,故障前要重视隐患、不要让它变成事故,故障后要认真复盘发掘隐患、避免再次入坑。

灰犀牛

灰犀牛是一个金融术语,比喻大概率且影响巨大的潜在危机;相对应的,黑天鹅比喻小概率而影响巨大的事件。灰犀牛理论来源:非洲草原上的灰犀牛,体形庞大、行动迟缓,远远看着似乎并没有威胁;而当它一旦被触怒、向你奔袭而来时,能够逃脱的几率微乎其微。

黑天鹅其实是一种偶发性、不可预见的,之所以叫黑天鹅,就是因为它突然出现,无法预防。灰犀牛事件不是随机突发的事件,而是在出现一系列警示信号和危险迹象之后,如果不加处置就会出现的大概率事件。从量变引起质变的角度看,灰犀牛理论跟海恩法则有些类似。



Prev     Next