DevOps学习心得与技巧分享

举报
小云悠悠zZ 发表于 2022/11/25 23:06:43 2022/11/25
【摘要】 DevOps从本质来讲只是倡导开发运维一体化的理念(MindSet)。这个理念的提出是为了解决很多企业面临的转型挑战,也就是将业务数字化,并且缩短数字化业务上线的周期,快速试错,快速占领市场。 DevOps并没有改变固有的软件生命周期:需求,设计,开发,测试,交付。但伴随着基础设施,软件设计方法等的改变,软件开发的思路,或者方式产生了比较大的变化。

云服务DevOps高级工程师学习路径课程进度概览.png

一、 DevOps 的本质

DevOps从本质来讲只是倡导开发运维一体化的理念(MindSet)。这个理念的提出是为了解决很多企业面临的转型挑战,也就是将业务数字化,并且缩短数字化业务上线的周期,快速试错,快速占领市场。

DevOps并没有改变固有的软件生命周期:需求,设计,开发,测试,交付。但伴随着基础设施,软件设计方法等的改变,软件开发的思路,或者方式产生了比较大的变化。

DevOps带来的最大好处是,软件生命周期数据链路的打通。

这不仅仅是运维和开发的结合。从顶层视角看,这是业务和生产的紧密结合。以前从业务和开发是脱节的。想要查看需求的实现进度,需要大量的人工汇报,更别提运营了。而现在以一个微服务实现一个特性的粒度来看,可以从需求,开发,测试,部署一直追溯到这个特性运营情况。这也是DevOps成为数字化企业基因的原因,业务和生产实现了完美的结合。

从敏捷实践的角度来讲,你会发现开发组织中参与者好似生物体中的神经元,大家各司其职,自成一体,接受反馈,并向外主动反馈。团队的自组织使得工作更加自然,能产生更大的效能。由以前的项目经理驱动,改为自我驱动的协作方式。每个人都可以给相关的团队以及责任人提需求,大家有机的协调在一起。

二、 微服务、容器和DevOps的关系

微服务只是一种设计思路,或者说他给出了如何用正确的方法来进行SOA的实施。理论上来讲他的确和DevOps没什么关系,但是从如何实践DevOps的角度来讲,微服务是非常有意义的。此外,随着诸如Spring Cloud以及微软Fabric等SDK的完善,微服务开发模式也逐步完善,实现了概念的落地

Docker可谓是一种敏捷化的虚拟化技术(较之虚拟机而言)。其实微软Fabric或者CloudFoundry也都脱离开容器的概念提供了微服务开发的解决方案,所以这两者并不是强绑定的关系。但是容器用不可变配置架构实现了微服务从开发到运维的质量保真度,这恰好解决了粒度小,数量多的微服务所带来的运维难题。再加上K8S,Swarm等容器云的支持,docker容器已经形成了事实上的标准。

如何利用这个强大的运行环境帮助企业敏捷,推进业务数字化,并且加快业务的投产? DevOps为上面所说的开发模式提供了软件生产线。

所以总结的来讲,企业业务敏捷是DevOps发展的直接推动力,容器云,以及微服务为DevOps提供了技术可行性。而敏捷帮助提高DevOps工作效能。

对于团队的拆分,这个问题真的要结合产品规模来看。团队的拆分有很多办法,贝索斯说的two pizza team,是建议一个团队中的人尽可能少,不要超过两个Pizza能吃饱的规模。用敏捷实践来讲,可以分为多个特性团队,以及维护团队,不同的团队各司其职,合理分工。在我以前的实践中,三个人可以做一个Feature,来交付一个月迭代的工作量。

当然将原有的巨石应用分割成更小的微服务是挑战很大的事情。因为理论上的微服务的设计对现有的团队组织结构,以及工程师设计能力都带来了一定的挑战。有些组织按照DDD(领域驱动的设计)的方式去实践微服务,会发现以前一个应用的复杂度变得很高,对项目管理来讲也是一件头疼的事情。现在有个比较新的看法就是,大家宣称做微服务(MicroService)的时候,实际上做的是迷你服务(MiniService)。迷你服务的粒度较之微服务的粒度更粗一些,关注度由一个域Domain,变成了能力。一个迷你服务提供一种能力,这种能力的提供也许是跨越多个域的。

最好的方法是以一个团队能承担的任务划定微服务的界限比较好,这样以来,不论是任务管理,代码构建,产品部署都会比较好做。

更关注服务的能力,这样也会减少因为跨域而带来的复杂事物处理。

三、关于DevOps学习和运维的一些注意事项

1、代码管理,很多公司对代码管理非常头痛,尤其是客户多了,版本就乱,一次升级就成了一场灾难,因此,代码管理确实非常重要。

2、项目进展管理,时间、成本和质量是项目管理的三要素,作为项目经理必须做好平衡。也需要协调好甲乙方资源,推进项目的完成。

3、问题管理,要常规运用事故管理的模式,对问题进行根源分析,提出改进意见。这里用好PDCA,RCA这些管理工具,非常有必要。

4、系统架构的稳定,架构不是一成不变的,也不应有普世标准。我们看《淘宝十年》就会发现,在不同时期,不同的体量规模下,淘宝的技术架构也在不断调整,稳定中的迭代发展是必由之路。但无论是什么时期,一个稳定可拓展的架构会让系统运维起来更顺利,体验更好。

5、测试问题,不说啥黑盒白盒测试了,反正我觉得测试这个环节做的蛮不好的,我们用的软件不说进行漏洞测试了,就是一些错误都是上线了再去发现。比较欣慰的是,医疗信息化软件未来可能会作为医疗器械进行管理了,这样一来,一定会提升行业对测试工作的重视程度了。

6、知识积累及传递,一个公司一个部门多年的实践经验的总结,这些总结需要靠时间的积累,在经验和教训的积累下慢慢沉淀。当你拥有了丰富的行业知识,你也就成了老油条了。一个团队需要从老油条身上提炼出老油来,这样对于公司和单位的能力提升都很有好处。小鲜肉一抹此油,容光焕发呀。

7、运维前端可配置,与用户接触最紧密的就是我们的运维工程师,用户对他提出的需求也最多,系统的灵活性体现在他能运用何种工具对所管理的系统进行客户化配置,以适应客户的大量且多样的需求。如果运维工程师啥都干不了,不但影响公司形象,也会大大拉低研发工程师的效率。

8、性能监督和度量,监督和度量能够让我们了解系统的瓶颈和改变方向,尤其是利用一些锚点设置,更能了解用户的习惯,促进用户画像数据的产生,从而做到比用户更了解他自己,做出更好的产品。

9、团队建设构建协作共进的IT文化,协作共赢,相互信任是DevOps的初衷和追求目标。而要达成这个目标,就需要培养团队成员之间的认同感。这种认同感不仅是在工作中产生,也需要通过文化进行熏陶和培养。

10、采用必要的自动化管理工具,很多新的工具确实是当年没有的,一些新技术的运用,也让当年的一些模式和方法需要改进。自动化的工具会让我们工作更有效率,沟通更顺畅。

关于DevOps具体如何学习大家可以参考以下链接:https://developer.huaweicloud.com/signup/d7569f6c14bf4770975ccc8bb9e8aa87

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。