运维工程师到底是个什么鬼

———————————————上篇————————————————

前言

现在最前面，这篇文章一共分为两部分，第一部分主要是介绍运维工程师到底是个神马鬼工程师，他真的是每天跑机房，每天装机的么？第二部分是围绕运维工程师介绍技术栈以及运维体系架构。

运维工程师，在英文里面名为 “Operations Engineer”，看字面意思，貌似的确就是操作服务器、管理系统的工程师。我们可以根据公司大小的不同，把它分为两个大类：Ops 和 DevOps。Ops 即运维，DevOps 即开发运维。让我们举个例子来说明一下。

Ops

小明，当年从学校毕业，熟读《鸟哥私房菜》N 遍，掌握了一手 Linux 操作命令。觉得自己已经碉堡了。遂进入一家创业公司，开始了第一份工作。

公司这个时候需要搭建一个网站，但是没有机房没有服务器。小明说：我来定服务器型号和装系统吧！遂刷刷刷选定了一款 Dell 的服务器，插上了 N 条内存和几块硬盘，装上了系统。剩下的譬如机房网络等就交给了网络工程师负责了。

Ops 必备技能入门款：
    1、了解服务器基本型号。
    2、熟练掌握使用系统安装。

好，服务器装好了，系统跑起来了。公司现在有 3 名开发工程师，小明分别为这 3 名工程师添加好了用户，并配置好了 SSH 让他们可以远程登录服务器。同时配置了一下 Nginx，让大家可以直接访问 WEB 界面来调试代码。

Ops 必备技能基本款：
    3、熟练掌握服务器配置、添加用户等基本操作。
    4、了解 Nginx、SSH 等常用服务。

随着公司的开发人员越来越多，以及服务器越来越多。小明觉得自己已经力不从心了，每天都在帮人给每台服务器添加账户，添加管理配置，跑机房重装系统。他觉得自己不能这样，这样效率实在太低了，而且现在他管理的机器已经乱成一锅粥了，每台机器的配置、分区、包全部都不一样，导致开发那边经常会说：

• 小明！为啥这台机器的根分区只有 10G，我其他的机器都是 50G 的！

• 小明！我这台2台机器怎么连 apt-get 的源都不一样，装的包的版本都不同！

• 小明！我这两台机器怎么一台 128G 内存，另一台只有 16G， 跑毛啊。

所以小明决定整顿一下把他们全部规整起来，制定了服务器的标准。同时在网上寻找了一些开源软件，以实现服务器的批量管理。

Ops 必备技能进阶款：
    5、熟练使用 Cobbler 等工具实现自动网络安装。
    6、熟练使用 Puppet、Saltstack、Ansible 等批量管理工具统一服务器基本配置。
    7、定制服务器的规格以及系统标准（系统版本、分区、预装软件等）。

从此以后，小明再也不用跑机房装机了！（所以运维工程师不是每天都跑机房的！）

同样，随着公司的发展，网站访问量的增多。系统相关的问题以及需求也越来越多。网站经常会出现各种奇奇怪怪的问题，譬如 Nginx 服务器请求量特别高的时候发生丢包情况、内网机器时不时会丢包连不上、服务器 closewait、timewait变得特别多、虚拟机的 ksoftirqd 进程 CPU 占用特别高等问题。小明开始惊慌失措，完全不知道怎么解决。这个时候公司来了一位高级运维工程师，带着小明解决了各类离奇问题。

Ops 必备高级款：
    8、熟练掌握系统 sysctl 中常用参数的定义以及影响。
    9、熟练掌握 iptables 的配置。
    10、熟练掌握 /proc 以及 /sys 目录下各个目录以及文件的含义。
    11、通过经验的积累，逐步培养出遇到 bug 快速定位问题的能力。

到此为止，Ops 相关的工作基本完成。

DevOps

随着运维工具化的逐步完善，现在小明帮助开发完成操作的时间已经可以用秒来衡量了。可是小明遇到一个棘手的问题：他需要每天 24 小时待命去解决开发扔给他的问题。小明现在是看场电影也担心有人找他。

这个时候，他觉得需要有一个运维平台，代替他完成这些重复性的工作。

小明初步规划了一下，大概总结出了以下几个需求：

• 服务器自助申请，开发自行申请服务器，系统自动分配可用服务器。

• 服务器装机的自动化，开发可以自行重装系统。

• 服务器权限的自助申请，开发可以自行申请服务器的权限。

• 服务器基础配置以及应用自动化，可以让开发自行配置服务器包版本、Nginx 配置，并自行刷到服务器上。

同时还有以下需求，运维自身的需求：

• 服务器状态报警，譬如网线或者硬盘坏了，服务器挂掉了。

• 对服务器的使用情况管理，定期发报告统计服务器的使用情况。

• 对服务器操作的审计。

小明把需求列出来之后，认识到自己面对了一个非常巨大的挑战。总结就是：

DevOps 必备基本款：
    1、了解数据库基本操作。
    2、熟悉至少一种后端语言（大部分DevOps都是用 Python）。
    3、熟悉 Html、Css、Javascript 前端语言。

小明花了很长的时间，学习并大概写了一个前端出来。大概是这样的

他咨询了一下开发，觉得他写的前端怎样。开发望了一眼，口吐白泡。

小明觉得这样不行，遂继续学习，他发现前端的框架都好漂亮，遂决定一试：

DevOps 必备进阶款：
    4、掌握 Tornado 或者 Django 等 Web 框架。
    5、了解 API 规范（RESTful 规范）等。
    6、熟练使用前端库以及框架，譬如：jQuery、Highchart、AngularJS、ReactJS 等。
    7、了解设计理念，尊重设计规范。譬如 Material UI，Bootstrap。

经过漫长的学习，小明终于把前端写出来了，大概是这样：

开发用过，都说赞。

然后，小明发现一个问题。他发现整个运维体系都特别的松散，没有一个完整的规划。基本都是开发需要什么，他们才做什么。所有的功能也是东一个西一个。

应该有一个非常明确的运维规划，将所有运维相关的服务都整理汇总并串联起来，才能做到有条不紊、环环相扣。

DevOps 必备高级款：
    8、……

欲知后事如何，请听下回分解。

———————————————下篇————————————————

关于 Windows 平台，现在互联网公司大部分用的还是 Linux 环境，对 Windows 环境，其实思路都是差不多的。只不过并不是特别了解。

然后是有人说到 “网络工程师” 去哪了，好吧哈哈哈哈如果是小公司其实对网络的规划是比较弱的，当规模变大之后才会考虑到网络规划、划分 VLAN、交换机选型规划等，本文就先不涉及啦~

同样，对于前端，后端的所需要掌握的技术，其实并不需要特别多。举几个例子：

对于后端，你完全不需要考虑使用 Tornado 的异步框架来提高处理能力，你用 gunicron 跑多几个进程就好了，虽然这样会比较占用系统资源，但是简单吖，开发快啊，上手即用啊。

而对前端来说，你根本无须关心兼容 IE ，甚至你根本不用去兼容老版本的 Chrome，甚至如果你们没有人用 Safari，你也不用去关心。因为对于面向程序员的 Web 应用，他们基本都会使用较新的浏览器。兼容性不是问题，你打开自己常用的 Chrome，点一点功能，看一看样式，没问题就过了。

（专业前后端工程师请不要揍我，小弟知道小弟没有写单元测试）

梳理流程

小明经过之前的努力，虽然把各个功能都写出来了，但是功能都特别的零散。所以他开始思考怎样才能构建一个完备的系统。他觉得有必要过一遍服务器从采购到交付的所有步骤，这样才能把整个系统的架构确定下来。列出来之后，小明把每一项都对应到了运维系统当中，非常明确的目的导向型的架构。

1. 开发发现自己的服务器资源不够了，决定需要采购服务器。

• 怎样发现自己的资源不够了？ =》资源使用量功能统计（对监控数据进行汇总分析）。
  

• 通过报警，还是报表？=》定期告知负责人的服务器的负载，如果负载超过某个阈值自动提醒。
  

2. 开发提出需求，需要服务器资源。并告知服务器的配置。

• 开发怎么确定自己需要怎样的服务器型号？ =》规范服务器型号，规格。
  

• 在哪里申请？直接找你么？ =》服务器自助申请页面。
  

• 申请完成之后，状态是怎样的？ =》运维及时在系统中更新服务器申请进度。服务器可用时自动通知。

3. 将服务器配置单交给服务器供应商，供应商开始准备服务器。

• 怎么提交配置单？人手工发？ =》供应商采购信息页面，审核通过后自动发送。
  

• 准备好之后？的信息怎么录入？ =》 提供给供应商接口，让其在准备好服务器之后录入服务器的信息。（对应机器的 mac 其实就够了，其他信息在机器装好之后可以直接调）

4. 服务器准备好后，快递到机房，并上架。

• 邮件功能，告知新的服务器需要上架。

• 
  

• 机房怎么知道上到哪里去？ =》上架功能。将机柜位置以及 U 位、交换机口信息全部维护起来。系统会自动寻找空闲机柜，为新的服务器分配机柜、U 位，并分配交换机口。

5. 安装系统。

• 服务器的管理口 IP ，以及系统 IP 怎么分配？ =》 IP 管理功能，维护所有服务器的 IP 地址。并可以通过接口调取可用 IP。
  

• 怎么装机？用 CD？ =》 PXE 网络安装系统（可以用 Cobbler, 当然如果你觉得它太庞大，可以试试 PyPXE）。

6. 服务器列表管理。

• 服务器太多了，我已经不知道我们有多少台服务器了。 =》服务器信息汇总页面，所有服务器应该都在这个页面当中（Saltstack 的 `salt-key -L` 不错）。
  

• 我想知道我有多少机器怎么办？ =》把服务器与负责人一一绑定，支持查看别人的服务器信息。

7. 系统环境。

• 系统装好后，各种基础包，个性化配置怎么搞？ =》 Saltstack、Ansible、Puppet 等自动化工具的调用。
  

8. 开发权限的管理。

• 开发现在这么多，服务器也这么多，怎么管理？ =》开发人员 SSH 的管理页面（自动化工具都有管理 SSH key 的功能，你指需要封装一下后端，实现下前端就好啦），自助申请服务器权限页面。

9. 应用的个性需求。

• 不同的应用需要不同的基础包或者坏境，怎么破？ =》 封装自动化工具的接口，让开发可以自行管理自己服务器的模板。

运维架构

经过这样梳理之后，小明觉得自己的运维系统的框架大概出来了，剩下的就是一个一个去实现了。汇总一下各大类，其实一共就是 4 大块的内容。

IDC 运维

管理机房以及网络相关的东西，譬如机柜、U 位的规划，网络、网段的规划。上面提到的自动分配机柜、U 位、交换机、IP 等就是在这一层完成的。

硬件运维

包括了采购服务器，上架这几个部分。同时服务器列表，以及容量的规划也是在这一层做的。

系统运维

包括服务器的安装，服务器基本环境的部署。以及开发 SSH key 的统一管理。

应用运维

开发的权限管理，服务器个性化的模板管理。

其他

这里面还有一些没有提及到的，但是同样非常重要的。譬如机器硬件的报警、系统使用率的报警。运维相关的报警是比较复杂的，在这里先不详细说了。

架构的进一步思考

小明其实知道，现在这样一个到处都是 “云云云云” 的时代。随便一个云平台，都号称 ”1分钟“ 为你准备好一台可以使用的机器。

小明看了一下自己的这个架构，仔细想了一下，我们现在申请一台机器需要 1 周左右的时间，简直不能忍。如果我提前买好服务器，是不是就可以解决这个问题了。

经过若干秒的思考，小明仰天一笑： ”Server as a Service"。看来可以引入服务器池了……

———————————转自：https://zhuanlan.zhihu.com/p/20227654—————————————

转载于:https://blog.51cto.com/jinyudong/1959157