- 前言
刚写完公司的年终考核总结，还有点余温，结合今年工作以及在一些运维群里跟各位老哥吹逼的体会以及对一些网红开源产物的学习和了解总想写点啥。也算是我个人对运维工程师这个岗位的看法吧。
一. 校园风的IDC
1.从服务器架构图说起
在四年大学生涯中唯一拿的出手的可能就是毕业设计里面搭建的这个集群，然后跑了一个山寨汽车之家的demo
2.谈谈这个架构图
虚拟化：
当时大概划分了30台刀片机给我们小组，最开始是虚拟化平台的选型。当时我们选择了时下最流行的kvm，然后30台刀片机都装了kvm，如何让这些虚拟机能被集中管理呢？这个时候我们的老师老杨（一个牛逼的phper，pythoner，Cer，开发架构运维啥都会）告诉了我们一种牛逼的虚拟化平台，叫做RHEV，这个是红帽的虚拟化平台。也就是可以把这些不同物理机上的虚拟机集中起来管理。当时感觉：卧槽 真尼玛牛逼，居然还可以这样玩！！这样一个linux上居然可以跑N个linux，这比以前人家说的装双系统牛逼多了呀。 好吧，原来这时候的我确实是个土鳖，连虚拟化和双系统都能搞在一起。工作之后听说了更牛逼的一个神器 叫做openstack，哎，反正这种开源软件嘛 都要分个社区版和专业版，当时在家里搭了一下来着。感觉，卧槽！这尼玛更牛逼了呀，居然能生成一个url，传一波乱七八糟的md5码就可以连接到服务器？当年我的rhev管理的虚拟机还要用vncviewer才能内网连接。科学真神奇~
当时拿到服务器之后，只想和刘胖子去嗦一碗粉，并且叫上老谭和零食偷吃者老张扬。嚯哟，摸到了真正的服务器，听到风扇的呼啸，高兴的像个3 5岁的猴子。忙前忙后，做raid，做vg，做lvm，规划分区，装kvm，部署rhev，对lvm做快照，用快照创建vm虚拟机，用虚拟机克隆创建另外的虚拟机，简直感觉自己天下无敌毫无对手。一台刀片上跑了十几二十个vm，开机半年，伴随着风扇排出来的热气和夏天的燥热，真的很酸爽。就这样子，我们居然搞起来了 “云平台” 有没有！cloud~ cloudstack~
程序设计
当时完全没有考虑要做一个什么高大上的应用程序，就连给催命鬼“全老师”做的开福区第某小xio的校园网还是老大哥给我的源码我乱改的。估计就是这个时候注定了写了3年图书管理系统的我不适合做一个开发吧。花式图书管理系统C版 delphi版 .net版，说好的要学习做游戏呢。因此走上了一条运维不归路，这真不是一条康庄大道~~说出来都是泪。当时市面上吹的最火的是啥，学linux当架构师，年薪30万运维之道。小伙子们，莫听这些龟八七糟的毒鸡汤了，还不如去买两本俞敏洪老师的毒鸡汤来看或者跟着老杨学python。但是呢，为了验证这套架构，我们得有基础的demo吧，所以搞了个java弄了个增删查该，再贴了几张奔驰宝马还带百度logo的烂图片就开始了运维之路。不过麻雀虽小，五脏俱全有木有，我们的奔驰宝马可是upload到服务器上的img目录里面的，别看我们只有一个单表的增删查改，我们可是做了读写分离的有木有。我们要实现的是什么呢？其实也就是那几年最主流的网站部署技术啦，动静分离和读写分离。为了提高性能，我们还要加各级缓存，最后变成一只装了电动小马达的蚊子。
划重点：装软件啦
————————————————————————————
前面说这么多废话，其实就是为了引出这里，这就是以前
甚至现在很多运维在做的事情，毫无技术含量的装软件，
从windows装到linux，从weblogic装到tomcat，从oracle装
到mysql，从redis装到MQ。从甲方装到乙方，从丙方装到
丁方.....我怎么是个废话奇多的男人？omg，叫我废话玛奇朵
吧。其实就是为了凸显出传统运维的特质：简单、重复、低效
—————————————————————————————
再回到正题，有了这个demo，我们就要开始部署了哟。
no.1 服务的运行（快手厨师风）
应用层，为了把java跑起来，需要一个mysql+tomcat 装上；
数据库，为了保证数据库的性能，mysql读写分离 装上；
为了保证tomcat的高可用，多个tomcat，装上
为了保证数据的安全性，实现在线同步 mysqlA-B主从同步 装上；
为了发布以及备份，rsync文件同步服务器，装上。
听人说tomcat对连接处理性能撇，nginx，装上；
听人说nginx不能单点，好吧keepalived，装上；
听人说keepalived不能单点，好吧，再做一个lvs，再搞个HA-heartbeat，这尼玛冷备份总算稳妥了吧，装上装上都装上；
好嘛，接下来是我们的img目录了，我们要实现，一打开我们的汽车之家山寨版，图片嗖嗖的就刷出来了（我们可是下载了最牛逼的百度高清带水印版盗图）
经人介绍，我们被科普了一个好东东，叫做cdn，嗨呀，我猜你们好多人肯定不晓得这三个单词是啥意思内容分发网络有木有，咋分发？肯定是根据源地址来分发啦，就近回源哦~上海人访问我的网站要请求到上海节点，北京人请求就请求到北京节点。
于是，又开始装软件了哈
no.2 缓存
dns服务器装上，上面做了异常多的解析，北京人访问解析到beijing.img.com 上海人访问解析到shanghai.img.com,然后这些地址分别A解析到我们部署的N套系统上去，龟龟，这么简单的cdn感觉在弹《小星星》 。看客莫急~这还只是智能解析部分，我们cdn最大的作用在于缓存后端的静态资源，所以呢，我们又搭建了一些cache服务器，当时好像是用squid和varnish搞的吧，具体的忘记了。然后在nginx上本身又开启了cache，简直太高大上了。
no.3 日志分析
经过我们这样的一波骚操作，以及搭建里面的各种访问测试，我们生成了MB级别的日志。好了，我们现在要做离线日志分析了，又经度娘介绍，我们下载了一个贼难搭的软件 hadoop~ 从它的大象标志就看出来了，这个软件不简单，就是为了拿来分析我们的MB级日志 话说人家不是拿来搞TB级日志的么？不管了，搞上搞上都搞上，什么高大上用什么。
no.4 运维监控
这次不是经人介绍了，确实是有“痛点（我不是鹅厂的）”才想到要搞这个东西。为啥嘞？前情提要：我们有30多台物理机，上面跑了很多虚拟机，在搭上面的集群的时候经常这里404那里502，完全找不到原因。结果查下来才发现是这里被老谭搞了个iptables，那里被老刘胖把机关了，真是搞死个人嘞。那时候最先进的是zabbix，用的最多的是nagios，这个东西真的把你弄死，看下当时的部署文档吧：
装软件还不够完，还要手写shell依次去上报服务状态（它提供了一个目录，有点类似于zabbix的模板，里面很多现成的脚本）
折腾了好几天才搞起
就是这样的lowB shell 要写一堆 真的累
不过嘞，总算给黑盒里面点了一盏微弱的蜡烛，美滋滋。不要问我vrrp，不要问我单播组播原理，不会不会 全部忘了。
no5.连接服务器
搞了这么大一个摊子，就像堆的积木，我是真的怕哪天被人家
ansible all -shell -a "rm -rf /"
所以，又谨慎的搭建了一波pptpd，还用证书连接，这就是vpn服务啦。
二、Real public cloud
1.从公有云说起
盗用了一波阿里云官网的行业解决方案服务器架构图，我来简单的聊聊这个架构图吧。对比两幅架构图，我们可以清晰的看到，真正的公有云是一个简单易用的资源池。只需要输入我们要实现的功能，就能得到我们想要的结果。无论是基础资源，还是应用扩展，甚至一些开发套件，应有尽有
no1.产品介绍
_
前面已经提到了各种简单无聊的工作，就是为了装软件服务，那么云时代应该做什么呢？其实上面我们自建虚拟化的时候已经用到了很多雏形了，那么我们把它们映射出来吧，应该很多同学就会跟我一样感同身受了。
_
映射关系表：
云服务器ECS(vps cvm)——装kvm
阿里云控制台(飞天操作系统)——openstack
块存储 （各种云盘、快照、镜像）—— 阵列卡、软raid、vg、lvm，逻辑卷快照
VPC(nat网关、弹性网卡、安全组、虚拟交换机、安全组、弹性EIP、各种形态的带宽计费包 vpn 专线 路由表 云企业网)——自建nat网关、物理交换机、物理网卡，物理防火墙、运营商拉线分配公网IP、流量费用
云存储（OSS、CDN、视频点播）——varnish、fastdfs、squid、nginx_cache
maxcompute（大数据计算服务）——hadoop
RDS（各种引擎的nosql和sql型数据库）——mysql mongo oracle redis sqlserver
云监控（站点、进程、资源水位）——openfalcon、zabbix、cacti、nagios
负载均衡SLB——lvs+nginx+keepalived+HA+heartbeat
no2.回到解决方案架构图
有了上面的基础产品介绍以及对比，我们再要去部署一个业务系统就很方便了。再也没有繁杂的配置，甚至不需要控制台，直接通过ROS（资源编排）就能构建出一套完整的系统，并且我们能通过ESS（弹性伸缩）预判资源水位实现动态扩容。在安全方面，有安骑士（服务器安全）、态势感知（服务器+web感知） waf（web应用防御）等，在公司内部，又有ram对阿里云资源进行分配管理，实现起来就很容易了,如果有一些短信告知的服务，甚至可以通过阿里云短信服务配置内容发验证码到手机，再也不用直接去找运营商买服务了（比如前几年火的易信什么的）。
*__
plus：这个图其实已经过时啦，按照我的观念，这应该是云1.0时代吧(提供基础计算资源、以及部署好的saas服务)。在倡导云原生、devops的时代里面，后面我将重构并且具体的说怎么样使用云，在后文中我会提到。
_
三. 讲究敏捷的时代
_
_
- 前言
_
上面讲到的那么多操作，虽然脱离了自己去部署底层资源（IaaS）但是避免不了还是要在阿里云控制台做很多配置管理的工作，并且也是重复低效的劳动，很没有产值。对于小公司而言，再招一个这样的专员来做控制台的配置管理是一件很浪费资源的事情。因为一般初创公司没有什么业务，几台服务器，一个负载均衡，几个域名 over
_
在云原生的时代，淡化服务器是一个很重要的突破。公有云交付的不再是一个由各种产品组件组装起来的服务器；而是一种叫做弹性容器实例ECI的东西，它完美契合kubernetes的理念，能够部署解耦后的各种服务组件，并且被kubernetes编排在一起。在kubernetes内部，能实现资源管理、调度、以及服务应用的编排。
也许，很多运维都经历过后面一大堆开发抢着要发包的年代
拿我来说，一天要发几十个版本，由于是政务系统，思维的陈旧使我不得不从ftp一个一个的把包丢上去， 然后重启服务，测试，验证。如果回滚，这个流程再重复。每天干到三更半夜，又有什么意义呢？换句话说，我奶奶都能做，一旦我奶奶都能做的活儿我要每天重复做，这个时候危机感就会诞生，一旦可替代性太强，那么注定工资低且失业系数高，这也是当前很多运维“工程师？”的现状。
no.1 从医疗系统业务架构说起
no.2 如果我要跑在k8s里如何规划业务
no.3 从校园IDC架构谈到k8s
no.4 阿里云容器服务devops指北
四. 运维生存分析指北
昨晚写的意识模糊了 有点虎头蛇尾
后面我将着重以实验为主写完这篇文档
^_^