―――――――――――――――上篇――――――――――――――――
前言
现在最前面，这篇文章一共分为两部分，第一部分主要是介绍运维工程师到底是个神马鬼工程师，他真的是每天跑机房，每天装机的么？第二部分是围绕运维工程师介绍技术栈以及运维体系架构。
运维工程师，在英文里面名为 “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―――――――――――――