美文网首页
DevOps应用:变更在DevOps中应用及企业级云安全管理框架

DevOps应用:变更在DevOps中应用及企业级云安全管理框架

作者: 北京老李 | 来源:发表于2017-11-13 23:11 被阅读0次

    作者:北京老李:DevOps布道师、IT管理咨询师。拥有EXIN Agile、EXIN Lean IT、首批EXIN DevOps Master讲师、首批ITIL Expert讲师、PMP、Prince2专家级、EXIN云安全管理、注册信息安全讲师(CISI)、ISO20000 LA、ISO27001 LA等多项认证。先后在北京、上海、广州等地主导软件开发、系统集成、咨询服务等工作,主要研究方向云安全管理、DevOps落地实施。

    本文的拟写自来与Martin刘老师的讨论,也感谢Martin刘老师找到了下面这个链接的图片,Martin刘老师说,看个文章还看到了北京老李和上海孙老师当年的模样:(~

    当前的讨论,很是久远的历史,但值得回忆:)

    北京老李说:得感谢互联网,哈哈。来看看孙老师现在的模样。看看北京老李和Martin刘老师现在的样子:9~~岁月在Martin刘老师的脸上,也在北京老李的脸上:(

    Martin刘老师、上海孙老师现在的模样,当你老了,化妆也没

    也让北京老李这个首批ITIL Expert回忆起当年从事IT管理的初期的讨论与研究,也正是在不断地项目实践中,进一步进印证了,IT管理的重要性,虽然时光荏苒,但我们在新的IT管理体系下也在进行相同的事情。历史的回忆从ITIL的变更到DevOps的变更应用。下图为历史的回忆

    十年过去了,但不变的不仅仅是情怀还有管理思想,ITIL在当今流行的DevOps中还在发挥着效果,那么看下,什么是变更?在ITIL原文中变更是指一切对服务以及CI配置项的改变,包括增加、删除、修改。那么在DevOps下是否适用呢?

    正确的理解是适用!因为DevOps中的变更虽然进行了自动化,但也需要引入ITIL中的变更,因为DevOps没有必要自己再造一个已经有国际标准ISO/IEC20000,已经有最佳实践ITIL成熟多年的体系,那么就是引用。

    在ITIL中变更管理将变更分为三大类,分别是标准变更(Standard change)、紧急变更(Emergency change)、正常变更(Normal change)

    标准变更(Standard change):是指那些经过预授权的变更,主要针对那些低风险、经常发生,并且是有预先定义好的处理步骤的的变更。一般情况下包括每月固定更新的税表或网站样式变更等内容。

    其特点在于不需要再次经过领导审计,因为在变更部署前已经提前完成了审批。并且变更部署活动可以完全是自动进行的,但需要注意的是需要留下审计及跟踪的记录。在DevOps中也一样遵从ISO20000及ITIL的标准,只不就是进行了自动,智能化目前看标准变更也在逐步实现。

    紧急变更(Emergency change):是指那些要尽可能快地去实施的变更,比如解决一个重大故障,或打一个紧急的安全补丁。在紧急情况下,变更必须立即投入生产环境。一般情况下安全紧急安全补丁或紧急恢复服务。其特点是必须尽快解决的潜在高风险变更。这些变更通常需要尽快得到高级管理层的批准,在执行完成技术活动后,应立即进行记录归档工作。DevOps的践的关键目标是简化常规变更流程,使其也能适用于紧急变更。

    所以在DevOps中紧急变更想要应对紧急,并不是大家认为的只是紧急的变更来了就可以应对,这就需要提前进行紧急变更的预防管理。

    这里需要应急管理、连续性管理(BCM)、IT灾备管理(ITSCM)、安全事件响应(ISMS)等多个流程的提前定义才能做好紧急变更的处理工作,这个工作在ITIL高级课程 RCV中进行了很好的说明与描述。有空来听北京老李讲ITIL高级课成为ITIL专家:)

    北京老李:首批ITIL Expert讲师

    正常变更(Normal change):是指那些除了标准变更和紧急变更之外的所有其它服务变更。其特点是需要更高的领导进行评审或者在既定的审批组织CAB和ECAB进行批准。其中CAB是指变更顾问委员会,ECAB是指紧急变更顾问委员会。

    在最新的敏捷的道路上,很多组织的变更都是由于领导出差、评估不能及时完成,所以造成了评估的时间上的延误。

    我们在2012年在IT管理项目中就注意到了这一点,我们是通过移动办公平台,IOS、安卓等新应用的开发解决这一问题。能够实现立即审批,随手审批、一键审批,并且随着应用了BMC  BladeLogic等自动化的产品,加快IT的交付频率。

    那么对于变更我们是如何解决专业化的快速评估的呢?我们在银行率先实现了变更的标准化评审工作,随着自动化产品BMC  BladeLogic的应用,一起同步推进管理与技术的问题。

    在新的DevOps体系下,需要从管理与技术层面解决变更的效率,这个问题在大规模代码部署的情况下尤其突出。

    一般情况下我们都认为只有技术加快才能解决软件交付的问题,其实这是一个伪命题,因为技术动作的不标准化,还来的快速交付的后果就是上线死的快,上线BUG多。

    今天很多单位都已经进行了云了,传统企业也从竖井式管理上升到云管理,这种情况下更是需要管理的标准化与技术的标准化。

    曾经有人说过没有写过代码的工程师就不是好司机,在此老李想说,没有管理支撑的技术实现就不是好DevOps。

    在越大的组织下,需是需要IT管理,IT管理成为他们的管理抓手,你可以想像一下,大规模部署可能包含成百上千(甚至数百万)行代码,由数百个开发人员在几个月内需要快速地进行交付,那么这更需要各技术专业的协合配合。

    变更管理在DevOps下仍然发挥着他在云下管理的控制权及组织权,只要CABle建设得当,这依然是一个建设高效组织的必经之路。因为无论是在云下,还是传统IT管理,都不能离开组织的“闸门”。

    在云下,现在更多的强调的是自动化,智能化。但随着AIOps的流行,你会发现,前提依然是需要一个标准化的规则与策略。

    每个组织都希望“一口吃个胖子”。但管理的成熟度告诉我们这根本就是不可能的。

    企业管理的AI成功之路,就是标准化=》模板化=》自动化=》策略化=》智能化,但在此的前提是服务化。

    所以变更管理在新的DevOps需要有一个更加清晰的变更请求单(RFC)的定义,因为它里面定义了执行RFC的决策所需要信息,它是智能化的基础。

    很高兴在回顾这个内容,也让我们朝着智能化之路在前进,我们已经在策略化的路上,但前方的路还有很多困难,需要不断地规避风险和引入安全管理、云安全管理。下附老李在《云安全管理》课程讲到的内容,并会在本次云博会公开,先提前爆个光:)

    北京老李,云安全管理框架

    当年写下的“般若是体,方便是般若所起的作用,般若侧重体证,方便为适宜方法.知此先后,则进道已.”.今天写下“知行合一,道法相合,术器相应,才能鲲鹏直上”。----共勉        北京老李  手打版

    相关文章

      网友评论

          本文标题:DevOps应用:变更在DevOps中应用及企业级云安全管理框架

          本文链接:https://www.haomeiwen.com/subject/oxitvxtx.html