您好,欢迎访问专业IT管理知识分享平台

上传文档

当前位置:首页 > 文章列表 > 中小企业 DevOps 从 0 到 1

「流程管理」中小企业 DevOps 从 0 到 1

赵舜东

中国 SaltStack 用户组发起人

江湖人称:赵班长,曾在武警某部负责指挥自动化的架构和运维工作,2008年退役后一直从事互联网运维工作,历任运维工程师、运维经理、运维架构师、运维总监。《SaltStack技术入门与实站》作者,《运维知识体系》作者,GOPS金牌讲师。

前言

之所以叫赵班长,是因为原来在武警部队做运维,身边的朋友都这么称呼,外号就这样来了。

今天主要有四个课题:

  • 先聊一聊 DevOps;

  • 然后跟大家聊一聊运维知识的体系和职业发展;

  • 再是中小企业基于开源的 Web 架构演变;

  • 最后是全链略自动化体系;

1、DevOps杂谈

DevOps 我相信大家都已经不陌生了,这类的分享很多,DevOps 的1.0版本我认为是怎么做持续交付,上图右侧的是一个持续交付环。

DevOps2.0 就是构建IT服务供应链,有人问我学 DevOps 应该学什么?按照这些来学,敏捷、精益、持续交付和IT服务管理,想做好运维工作必须精通持续交付和IT服务管理,现在想成为一个 DevOps 工程师,敏捷和精益也是必需要去学的

DevOps CALMS 文化,我个人总结了一个运维的文化,称之为运维的批评与自我批评,下面这张图是我们武警部队的例会,一般在每周二开的“民主生活会”,以班为单位,目的就是做批评与自我批评

主要内容是每个人都发言,指出我们班在哪些方面做的不够好以及自身存在的问题。我认为批评与自我批评是一种非常棒的模式,值得推广。我个人做运维经理、总监的时候,我从来不会给团队成员说你想涨工资的话要努力工作,好好学习这些鼓励的话,我主要的激励方式是靠打击

我之前有一个理论是“鼓励”员工跳槽。你埋怨工资低,为什么不跳槽?。很多时候工资低不是企业的问题,是个人能力问题。

完整的文章,请访问下面链接:

《我为什么“鼓励”员工离职?》

我相信大家对这个话题都有自己的理解,我先说一下我的理解,在说之前我先发一个警告,我这个话题比较偏激,因为我要用这种相对“偏激”的话术来影响身边的朋友,不一定是对的,但是可以引起大家的一些思考

这就是我的运维“能力不行”论,其实总结起来就是要先从自身找原因,能让你快速的强大起来,所有的原因可能都是自身能力不足导致的。

举个例子,之前我在推动自动化部署落地时遇到很大的阻力,因为涉及到开发、测试、运维,很难推动。当时第一感觉是,队友是傻X。后来慢慢醒悟(因为我定期会做自我批评)。反思这个事情为什么会推行不下去,原因很简单,我的沟通能力不行!

大家认为成为一个更高级的工程师,拿更多的薪资是因为你的技术吗?大部分都不是,你拿多少钱不在于你技术的高低,而在于你能给公司带来多大的价值。有人觉得自己技术很牛,为什么工资没有那么高。你技术确实很厉害,但是没有给公司创造价值,这是切实的问题。这可能是你除技术外其它能力不行!

自动部署这个事情,我后来天天请做开发的哥们儿吃饭,大家觉得很奇怪,怎么用这样的手段?我天天找他,把关系处的很好,之后跟他说“兄弟,我现在要推自动化部署,怎么办?”找他协助,这也是一种能力,谁说人际交往能力不是我们工作必备的能力呢?当然其实后来我找了他四次之后这个事情才落地。

可能有人认为在第一次协商失败之后,就认为这个哥们儿不配合,不支持自己的工作。其实不是的,因为每个人都有自己的事情,你觉得重要的事情,别人未必觉得,千万不要先入为主!这是我的经验

很多时候我们总是认为别人有问题,其实真正是自己能力的问题。不管是什么原因,要记住,沟通也是运维必备技能之一,并不是掌握各种技术,很多时候软技能反而起很重要的作用。

我希望大家不要把运维能力局限于技术能力,尽量的把往外延伸。技术是成长的必备条件,但不是唯一条件

2、运维知识体系与职业发展

大家过年回家有没有跟家人介绍自己的工作,什么是运维?,前些年,我在家里就遇到过这个问题,我认真的回答后,有一个做Java开发的弟弟,想了半天,说他知道,就是网管。

这说明大多数人都小看运维了,所以我根据自己的一些经历,编写了运维知识体系,就是要告诉他人,不要小看运维,运维掌握的知识并不比其它职位少,甚至要多很多

整体是按照一个HTTP请求从客户端发出到服务端所经历的层和涉及到的技术,并没有严格意义上的上下关系。

存储层并没有按照文件存储、块存储、对象存储这样的方式来进行划分,而是统称为文件存储和数据存储。

基础服务和容器层,操作系统层列举了运维必备的基础知识

基础服务层,我们在做运维的时候有很多运维工具,自动化部署系统、监控系统都是我们做运维要做的,包括系统相关的如堡垒机这些

最后面我放了自己对运维产品化和服务化的一些理解

运维工作内容,这里只是做了一个典型的案例,在你们的公司可能不是这么划分的。不同的层面做的事是不一样。现在做运维其实开始场景化了。例如在招聘的时候,举个例子,我是做 CDN 的,我招人的时候肯定想招一个做 CDN 运维的。

做电商运维的,到另一家做电商的公司,发现薪资各方面都好谈。但是到一家做游戏的就不好谈,之前做电商的经验拿到游戏当中可能就不好使,或者不能发挥最大的价值。因为不同的业务对应不同的运维场景,需要的技术可能会有一些不同的倾向性

运维的技术层次,我做了一个发展的概述。

第一,搭建服务,这是我们运维最早做的时候,把服务搭建起来了,就会觉得很棒,很有成就感。

第二,如何才能成为一个高级工程师呢,就是用好服务,想要用好服务那就需要深入了解一个服务的底层知识,能够进行对应的性能调优,才能把服务用好。

第三,让服务恋爱,到这个级别我称之为架构师级别,可以让不同的服务根据不同的方式结合起来,完成对应的工作。

第四,让服务生孩子,就是产品化,这次大会咱们外面有很多展商,很多是面向运维的,运维的很多地方如监控、日志、作业平台、CMDB等等都可以做成一个产品来创业

之前有人问我运维的职业发展,未来怎么样发展,觉得很迷茫。

这里我做了一个选择题,架构师、运维总监、某个领域的技术专家,云解决架构师、业务运维专家,培训讲师、DevOps 专家等等。可以看到未来的方向有很多,可横向(解决方案)、可纵向(某一个领域专家)等。

就像我刚才做的一个运维知识体系是用来让运维人员找准运维的边界,做好运维要掌握的知识很多,但是需要给自己划一个边界,刚才所说的所有关健词,只要掌握一个就可以够研究一辈子了,每一个领域深入下去会走的很深

3、中小企业基于开源Web的架构演变

中小企业基于开源 Web 的架构演变,这个部分尽量加速略过。因为分享时间有限,我用了很多图来更直观的展示:单机、机群、文件、缓存、数据、异地灾备。

单机时代在Web架构上非常简单,单机时代我们关注的是单机的性能优化,这是很多人忽略的问题。

组建分离,我们的图片要使用独立的顶级域名。比如说我之前是做电商的,需要写很多cookie到用户浏览器,如果都在一个顶级下,由于Cookie作用域的关系,别人访问图片的时候浏览器也会发送cookie 到图片服务器,这完全没有必要,可以使用独立的顶级应用来避免Cookie提交。

单机时代主要关注的是 Web 性能,咱们做运维的,尤其是想面试高级工程师,现在到公司面试问的全都是基础问题。原因很简单,会基础了,其他的不会没关系,只要基础扎实就可以很快掌握,但是基础知识不会,遇到问题就很难快速定位和解决

session 的处理方案总结起来有三种:一是会话保持,一个IP进来的可以固定访问到集群中的某一台后端机器上。还有就是 session 复制,基本上不建议使用,曾经6个节点的 Tomcat 集群做 Session 复制就会出现各种问题。最后 session 共享是终极解决方案。

很多人会被文档把思想固化住,要记住别人写的东西未必是正确的,我可以说我今天讲的也未必是正确的,一定要学会分析,然后沉淀成自己的东西。就像网上有一种文档,就是你照着做,一定不会成功

阿里开源的 Dubbo 是一个成功的开源 SOA 框架,帮助了很多公司,不过现在我司的一些服务正在从 Dubbo 框架迁移到Spring Cloud。这里不讨论孰优孰劣,真的是看具体需求了

架构再往下发展就涉及到分布式部署,看看腾讯的分享,它们在这方面会做的比较好。

存储层面:0.tmpFS,最早玩 Squid 的时候,直接是挂载一个 tmpfs 文件存储,性能特别的快,因为 tmpfs 是占用系统的共享内存。

1. 本地硬盘

2.DAS 存储

3.SAN 存储都是块存储类型。

在做Web架构的时候,除了块存储用的最多的就是文件存储。在集群架构中,文件存储可以使用例如 NFS 的共享存储,还可以使用文件的分发和同步。还可以进行多级的分发。

我司是在标准化的原则上,统一用分布式的文件系统 Glusterfs 来做,早期图片是用的 MooseFS 。还有一个系统是用 FASTDFS,对于做小视频或听书类的服务,每个文件大概是5M-20M左右,用 FASTDFS 特别合适

讲完集群和存储,就到了Web架构中的缓存,我编写了一个《Web 缓存知识体系》,因为我在学习缓存的时候发现所有人的文章都是一个点,想把整个面都串起来的文章找不到,所以就自己把缓存的体系串联起来。我们通常所的缓存,会包括读缓存Cache和写缓冲Buffer。这里只聊读缓存 Cache。

DNS 缓存,浏览器的 DNS 缓存,比如说 firefox 默认缓存60秒,操作系统DNS 缓存,DNS 缓存服务器,应用程序 DNS 缓存。浏览器是分发在千家万户的缓存代理,用好会非常的方便,所以浏览器缓存协商的三种方式是运维必会的,基于最后修改时间、Etag和过期时间。

代理层的缓存,反向代理反存,包括Web缓存,包括 Opcache 缓存。我之前在项目做过一个实验,我们是 PHP5.5,我开了 Opcahe 之后,我们的用户态CPU使用率从70%下降了40%左右。

做电商的对页面静态化比较了解,一般我们会有一个CMS系统,从后端服务集群获取到产品详细页、列表页等这些需要静态化的服务,然后将获取到的HTML本地缓存进行对应的修改后,直接使用Nginx发布出去。

聊完缓存在Web架构中,比较重要的就是数据库了

MySQL 的主从复制做例,目前我们用的最多的是主主复制,单写,因为双写有很多双写的问题,所以用

暂时没有评论,评论一个吧?

您需要登录后才能评论 , 去登录

Powered by DS文库

Copyright © 专业IT管理知识分享平台 All Rights Reserved. 鄂ICP备19005274号-1
×
保存成功