zoukankan      html  css  js  c++  java
  • DevOps 在没有一键部署(自动化部署)的情况下能做些什么

    DevOps 三D原则

    在上一篇文章中说到了DevOps的三弟原则。

    • 一键式部署(Automatic Deploy):部署过程中,标准化部署过程,实现一键式部署
    • 一次构建打包(Automatic Delivery):在测试环境、UAT环境和生产环境的流转过程中,只打包一次,软件包按顺序自动交付到各个环境,最终发布到生产环境
    • 一次配置分发(Automatic Distribution):在生产环境发布过程,建立统一的配置分发管理,将繁琐的分布式环境配置一次分发到各个数据中心,简化发布过程。

    最理想的状态当然是能够一键部署,但是很多中小企业从作坊式或者英雄主义式的方式发展到现在,想要一件部署可能需要整理很多流程,规范甚至会涉及到某些英雄代码的重构,设计框架的调整,必然会引起内部矛盾,在这样的情况下我们如何推进DevOps呢?以下是个人拙见,抛砖引玉了

    DevOps是一种方法论

    DevOps是一种方法论,任何方法论都需要灵活的运用才能产生价值,否则就是一堆理论,毫无价值。
    DevOps意在调动开发、测试、运维三方人才,进行“合体”作战,实现快速响应,如同Flickr实现每天部署10的要求,这对产品的热补丁提供了有效的理论支持。
    想要为DevOps和应用灵活性而重塑团队,需要领导层的勇气和无私奉献。当然,它也需要花费时间和金钱,并且需要在团队成员筛选上做出艰难的决定。
    为了促进DevOps战略,调整考核和激励机制是必要的。如果依然只根据敲出代码的生产力来奖励开发人员,或者根据基础设施的可靠性来奖励运维人员,那么,什么都不会改变。相反,应该奖励系统创建和运维的整体团队,并且根据团队工作的全部要素来确定奖励。

    不是所有的公司都如同Facebook的服务器一样多

    看看 Facebook在这方面目前所处的位置吧,举几个例子:

    • Facebook有数千名开发和运维人员,成千上万台服务器。平均来说一位运维人员负责500台服务器(还认为自动化是可选的吗?)他们每天部署两次(环式部署,Deployment ring的概念)。

    通过上面的例子我们知道,不是所有的公司都如同facebook的服务器一样多,在少量的服务器(云服务器)中,手动部署也是可以支持度过转型时期的。

    DevOps是服务于持续交付

    DevOps就是为了快速响应部署,持续交付,如果一个传统企业两年或者一年才交付一次产品,那也没有必要实施DevOps了,但是模块化开发能够减少软件偏离客户目标的可能性,让客户参与到软件开发过程中,持续与客户沟通,并且交付模块化功能能够提高企业可信度并且增加客户粘性。持续的交付更容易让客户掏钱为他的需求买单,因为他能够看到产品的进度,一切让客户感觉都在他的掌握之中。

    “敏捷”能为你服务

    敏捷开发是实现持续交付的基础保障,不论是scrum还是xp,无论是4周还是2周的交付周期都是持续交付的理论,这些理论可以支持系统模块化的功能持续交付客户,并且支持自循环的迭代优化。
    那么为什么要敏捷呢?
    我们必须明确,公司的目的或者客户的目的是什么,产片尽快投入使用,加快上市时间(TTM)。
    上市时间(即TTM)是指一件产品从最初的构思到最终可供用户使用或购买这一过程所需要的时间。对于产品很快会过时的行业,TTM是一个非常重要的概念。
    在软件工程方面,所采用的方法、业务,以及具体技术几乎每年都会变化,因而TTM就成了一个非常重要的KPI(关键绩效指标)。
    TTM通常也会被叫做前置时间(Lead Time)。

    协同工作

    传统的企业是这样的。
    这里写图片描述
    开发和运维之前是有一堵墙,各自都有各自的目标与愿景,很容易造成两个团队的对立。

    现在我们改变这一切,在软件开发、测试、质量保证(QA)、集成、预生产和生产部署等方面的任何旧小团队必须打散,因为每个小团队都可能拖延开发周期并且带来不可预料的问题,每个团队都可能有自己的目的。让消息畅通,协同合作。
    实现团队的自循环,从而打破混沌之墙。
    这里写图片描述

    人才是根本

    人心惟危,道心惟微;惟精惟一,允执厥中。
    说了这么多废话,人、才是根本。

    写在最后

    自动化部署是必然趋势,没有自动化的部署,风险会成指数增加。

    下面看一下手工部署成功的概率

    这里写图片描述
    - 只需手工运行5条命令的情况下,成功部署的概率就已跌至86%。
    - 如需手工运行55条命令,成功部署的概率将跌至22%。
    - 如需手工运行100条命令,成功部署的概率将趋近于0(仅2%)!

    http://www.infoq.com/cn/articles/detail-analysis-of-devops
    http://mp.weixin.qq.com/s/ZkqNpwuau9e4MN9H-EXg9g
    http://mp.weixin.qq.com/s/wZj3KuOXOJym6Bk_IbDjrg
    http://mp.weixin.qq.com/s/XMJyspySu3-XsYhL_nstMA
    https://baike.baidu.com/item/devops/2613029?fr=aladdin#7

  • 相关阅读:
    OLAP ODS项目的总结 平台选型,架构确定
    ORACLE ORA12520
    ORACLE管道函数
    ORACLE RAC JDBC 配置
    ORACLE RAC OCFS连接产生的错误
    ORACLE 启动和关闭详解
    OLAP ODS项目的总结 起步阶段
    ORACLE RAC 配置更改IP
    ORACLE RAC OCR cann't Access
    ORACLE RAC Debug 之路 CRS0184错误与CRS初始化
  • 原文地址:https://www.cnblogs.com/xiaoch/p/13417944.html
Copyright © 2011-2022 走看看