DevOps “八荣八耻”
这次OpsWorld大会分享的主题是: DevOps的八荣八耻
主要是通过几条通俗易懂的标语来分享一下开发和运维的互动以及架构设计上的一些心得,从思想上指导行动,技术上弯道超车,把架构设计的理念深入到研发和运维一线上,从而提升整体战斗力。
DevOps的八荣八耻:
以可配置为荣,以硬编码为耻。 以互备为荣,以单点为耻。 以随时重启为荣,以不能迁移为耻。 以整体交付为荣,以部分交付为耻。 以无状态为荣,以有状态为耻。 以标准化为荣,以特殊化为耻。 以自动化工具为荣,以手动人肉为耻。 以无人值守为荣,以人工介入为耻。
1. 如果重新选择,还会不会选择做运维?
其实不是工作选择人,而是人选择工作,一个人若对某方面有了兴趣,真正用心学习了近10000个小时,其实做什么都是可以的。比如说我毕业那个时候,都是强调复合性人才,根本没有运维这个职业,我们不光自学Linux操作系统,还学习编程,折腾网络,自己写论坛聊天室等程序,直到2010年,我都是以linux嵌入式系统工程师为谋生手段,但是Linux给我们带来的是每天都有创新的,好玩的,优秀的开源软件让我们保持激情去尽情的折腾和学习,当互联网兴起的机会来临时,做个运维总监其实也是顺理成章的事,其实,除此之外,我也可以做销售,做市场,做演讲培训,只有举一反三,触类旁通的才是真正的高手,头衔只是个虚称。
2. 推荐非常不错的书籍
《极客与团队》IT是个人才辈出,高手云集的行业,但并不是越强越好,也要在合适的时候,合适的机会,做合适的事,所以我推荐这本书,它从团队管理上去协调,及时发现和处理危机,从而让团队更加稳健,更具有战斗力。
《暗时间》时间管理并不是要把所有事情做完,而是更有效的运用时间。IT人大多崇尚自由奔放的作息,大多灵感驱动,这在项目/时间周期制度下会有一些冲突,但成功人士往往对时间管理都有独特的控制力,所以,认识自我,掌握时间管理技巧是每个人都会学习的本领。
《unix编程艺术》贯穿始终的 KISS 原则,无论是优秀的重量级人物之语,还是Unix世界上最优秀的软件作品,都极具教导意义,这本书是可以每每读来都有不一样的体会的瑰宝。强烈推荐
3. 运维除了技术能力之外,最重要的能力是什么?
首先这个技术能力,我觉得不仅仅是系统、网络的运维能力,还要包括对开发技术,如精通一门python语言,还要有很强的实践动手能力。除此之外,我认为最重要的能力是表达能力,因为运维大多数还是一个成本支出的岗位,如何把深奥隐晦的技术瓶颈,用直观的图表表现获取上层持续的投入是需要技巧的,然后面对你的同事,你的兄弟部门,也需要你的感染力去鼓励和协调,如果能够做到这些,说明你已经具备了领导的才能。
4. 运维自动化方面,分享一下实践经验
之前确定有一些自动化方面的经验,但是目前看来有点过时了,现在主要还是集中在Ansible,虚拟化,容器化技术。
5. 容器越来越普及,有没有在生产部署容器?
我们从2015有把云处理的业务迁移到openstack上,虽然虚拟化了,但效果一般,就是没有惊喜。于是在2016年,我们再次把云处理迁移到Mesos/Docker上,确实有惊喜。至于实践经验,说实话,docker的发展也是太激进了,我们目前还只是跟随,遇河搭桥,逢山开路,幸好容器圈的朋友都非常热情,总是能够找到对的人给一些指点,所以暂时没有好的心得。
6. 传统运维岗位会被取代,如何看待去对运维的冲击?
这是时代的变化,与其固步自封,不如积极拥抱变化。别多想了,活到老,学到老,还不得老年痴呆,这不是一举多得的美事。
7. 你对DevOps如何理解,你们是如何实践DevOps?
我的演讲会重点讲解DevOps在又拍云里的实践,谢谢关注。
8. 运维大牛出来创业,提供运维解决方案,你对运维创业如何看?
这很符合互联网+的思想,对一些运维能力不强,但运维又不是核心竞争力的公司来说,这确实是福音。我认为这也是市场存在的机会,但是对出来创业,给企业提供运维解决方案的大牛来说,确实是一个不小的挑战:一方面自己团队的实力要过硬,另一方面又挑战了运维牛人的软肋-做生意,而且运维这个背锅侠/黑锅侠,在甲方如何保全自身都是要面临的现实,所以,我很佩服这些有理想的运维达人,希望有用得着我的时候,让我知道。
9. 运维体系建议有何经验分享?需要重点关注的点有哪些?
做好运维的三大法宝:
- 运维自动化
- 监控常态化
- 性能可视化
除此之外,有条件的话,运维平台也要迟早设计,它能够帮助我们解决:
- 资源管理
- 人员管理
- 权限管理
- 行为管理
- 性能管理
重点关注的点:
- 通过有效的监控手段,通过资源整合,优化,复用,化成本部门为利润部门(可以参考王津银的运维演讲)
- 利用大数据分析,帮助运维快速查找症结所在,挖掘日志数据的潜在价值
10. 运维工具什么时候选择开源,什么时候选择自研?
对于运维来说,通常我们不会重复造轮子,但一定会用好轮子,或者把轮子改造得更加称手而已,选择自研往往具备了一定的开发能力,再加上某些原因,如:
- 找不到符合要求的开源软件,如我们自研的云处理软件…
- 开源软件有bug或者issue,社区短期内无法推进,但我们又急需,只能通过自研解决,如ats的内存泄露问题…
- 开源软件的功能特点跟公司的业务不相符合,不得不改造软件,如nginx的防盗链模块,需要与客户对接定制…
- 开源软件的设计目标过于高大上,通用性好也意昧着臃肿,如果我们只要某个小功能点,就不需要牛刀了,如性能探针的埋点…
- 有数据保护要求,或者有隐私的场合…