Linux因其高效率、易于裁剪、应用广等优势，成为了当今中高端服务器的主要操作系统，并且处于一个不可替代的地位。Linux可安装在各种计算机硬件设备中，比如手机、平板电脑、路由器、视频游戏控制台、台式计算机、大型机和超级计算机。随着Linux在中国市场迅猛发展，国内Linux人才缺口逐渐凸显。Linux人才招聘也成了当前最热门的招聘之一。
首先linux是一个非常非常大的概念。想全部吃透是不可能的。理想的说，搞懂linux，就可以做所有工作。个人更倾向于说想做什么样工作，需要学linux的哪部分。
按个人经验介绍下常见的linux有哪些领域，并对应到什么工作。
1）linux应用。这部分严格来说不能算是linux，只是跑在linux上的应用，比如web，网络，IT等，职业包括系统研发，后台开发，服务器性能优化，运维等；
2）linux定制。这部分涉及linux版本的用户包较多，内核会有一些涉及，主要各种商业linux的订制，服务等。比如redhat之类，不少是外国公司，国内大多招现场支持等。
3）linux内核开发。这部分主要是linux内核驱动的开发。几乎全部是编程工作。主要是芯片公司，以及使用芯片的产品开发公司。前者如intel，marvell，后者如中兴华为。
4）android衍生品。因为android包括慢慢火爆的tizen都用的linux内核，所以理由同3。所以手机芯片公司和手机开发公司也是linux开发者的雇主之一。比如高通，TI等；
一、Linux运维的主要工作内容
Linux运维作为众多工作中需求人数最多，薪资待遇最高的岗位，本文重点介绍Linux运维的职业，本文内容由专门研究Linux运维学习和职业发展的机构马哥教育和爱好者们联合撰写。
互联网Linux运维工作，以服务为中心，以稳定、安全、高效为三个基本点，确保公司的互联网业务能够7×24小时为用户提供高质量的服务。运维的职责覆盖了产品从设计到发布、运行维护、变更升级及至下线的生命周期。
产品的整个生命周期里运维的职责重要而广泛，但运维工程师们的职责不仅限于这部分工作，还需要总结工作中遇到的问题，抽取出相关的技术方向、研发相关的工具和平台以支持/优化业务的发展并提高运维的效率，相关技术工作主要包括：
服务监控技术：包括监控平台的研发、应用，服务监控准确性、实时性、全面性的保障
服务故障管理：包括服务的故障预案设计，预案的自动化执行，故障的总结并反馈到产品/系统的设计层面进行优化以提高产品的稳定性
服务容量管理：测量服务的容量，规划服务的机房建设，扩容、迁移等工作
服务性能优化：从各个方向，包括网络优化、操作系统优化、应用优化、客户端优化等，提高服务的性能和响应速度，改善用户体验
服务全局流量调度：接入服务的流量，根据容量和服务状态在各个机房间分配流量
服务任务调度：服务的各种定时/非定时任务的调度触发及状态监控
服务安全保障：包括服务的访问安全、防攻击、权限控制等
数据传输技术：包括p2p等各类传输技术的研发应用，也远距离大数据传输等问题的解决
服务自动发布部署：部署平台/工具的研发，及平台/工具的使用，做到安全、高效的发布服务
服务集群管理：包括服务的服务器管理、大规模集群管理等
服务成本优化：尽可能降低服务运行使用的资源，降低服务运行成本
数据库管理（DBA）：通过设计、开发和管理高性能数据库集群，使数据库服务更稳定、更高效、更易于管理。
平台化的开发：类docker等平台的开发管理，及服务接入技术
分布式存储平台的开发优化与接入
等等，凡是关系到服务质量、效率、成本、安全等方面的工作，及涉及到的技术、组件、工具、平台都在运维的技术范畴里。做好每一个技术方向、完成相应的组件、工具、平台研发都能对履行运维职责起到积极的作用，对业务的发展发挥关键影响。
二、Linux运维工作分类
运维的工作方向比较多，随着业务规模的不断发展，越成熟的互联网公司，运维岗位会划分得越细。当前很多大型的互联网公司，在初创时期只有系统运维，随着 模、服务质量的 要求，也逐渐进行了工作细分。一般情况下运维团队的工作分类（见图1-1）和职责如下。
图1-1 运维团队的工作分类
2.1-应用运维（SRE）：应用运维负责线上服务的变更、服务状态监控、服务容灾和数据备份等工作，对服务进行例行排查、故障应急处理等工作，工作职责如下：设计评审、服务管理、资源管理、例行检查、预案管理、数据备份。
2.2-系统运维(SYS)：负责IDC、网络、CDN和基础服务的建设（LVS、NTP、DNS）；负责资产管理，服务器选型、交付和维修，工作职责如下：IDC数据中心建设、网络建设、LVS负载均衡和SNAT建设、CDN规划和建设、服务器选型、交付和维护、内核选型和OS相关维护工作、资产管理、基础服务建设。
2.3-数据库运维（DBA）:数据库运维负责数据存储方案设计、数据库表设计、索引设计和SQL优化，对数据库进行变更、监控、备份、高可用设计等工作，详细的工作内容如下：设计评审、容量规划、数据备份与灾备、数据库监控、数据库安全、数据库高可用和性能优化、自动化系统建设、运维研发、运维平台、监控系统、自动化部署系统。
2.4-运维安全（SEC）：运维安全负责网络、系统和业务等方面的安全加固工作，进行常规的安全扫描、渗透测试，进行安全工具和系统研发以及安全事件应急处理，工作内容如下：安全制度建立、安全培训、风险评估、安全建设、安全合规、应急响应。
三、Linux运维日常使用软件和技能
运维工程师使用的运维平台和工具包括：
Web服务器：apache、tomcat、nginx、lighttpd
监控：nagios、ganglia、cacti、zabbix
自动部署：ansible、sshpt、salt
配置管理：puppet、cfengine
负载均衡：lvs、haproxy、nginx
传输工具：scribe、flume
备份工具：rsync、wget
数据库：mysql、oracle、sqlserver
分布式平台：hdfs、mapreduce、spark、storm、hive
分布式数据库：hbase、cassandra、redis、MongoDB
容器：lxc、docker
虚拟化：openstack、xen、kvm
安全：kerberos、selinux、acl、iptables
问题追查：netstat、top、tcpdump、last
运维以技术为基础，通过技术保障产品提供更高质量的服务。运维工作的职责及在业务中的位置决定了运维工程师需要具备更加广博的知识和深入的技术能力：
扎实的计算机基础知识，包括计算机系统架构，操作系统，网络技术等；
通用应用方面需要了解操作系统、网络、安全，存储，CDN，DB等，知道其相关原理；
编程能力，小到运维工具的开发大到大型运维系统/平台的开发都需要有良好的编程能力；
数据分析能力：能够整理、分析系统运行的各项数据，从中发现问题及找到解决方向；
丰富的系统知识，包括系统工具、典型系统架构、常见的平台选型等；
综合利用工具和平台的能力；
四、Linux运维工作发展过程
早期的运维团队在人员较少的情况下，主要是进行数据中心建设、基础网络建设、服务器采购和服务器安装交付工作。几乎很少涉及线上服务的变更、监控、管理等工作。这个时候的运维团队更多的属于基础建设的角色，提供一个简单、可用的网络环境和系统环境即可。
随着业务产品的逐渐成熟，对于服务质量方面就有了更高的要求。这个时候的运维团队还会承担一些服务器监控的工作，同时会负责LVS、Nginx等与业务逻辑无关的4/7层运维工作。这个时候服务变更更多的是逐台的手工操作，或者有一些简单批量脚本的出现。监控的焦点更多的在服务器状态和资源使用情况上，对服务应用状态的监控几乎很少，监控更多的使用各种开源系统如Nagios、Cacti等。
由于业务规模和复杂度的持续增加，运维团队会逐渐划分为应用运维和系统运维两大块。应用运维开始接手线上业务，逐步开展服务监控梳理、数据备份以及服务变更的工作。随着对服务的深入，应用运维工程师有能力开始对服务进行一些简单的优化。同时，为了应对每天大量的服务变更，我们也开始编写各类运维工具，针对某些特定的服务能够很方便的批量变更。随着业务规模的增大，基础设施由于容量规划不足或抵御风险能力较弱导致的故障也越来越多，迫使运维人员开始将更多的精力投入到多数据中心容灾、预案管理的方向上。
业务规模达到一定程度后，开源的监控系统在性能和功能方面，已经无法满足业务需求；大量的服务变更、复杂的服务关系，以前靠人工记录、工具变更的方式不管在效率还是准确性方面也都无法满足业务需求；在安全方面也出现了各种大大小小的事件，迫使我们投入更多的精力在安全防御上。逐渐的，运维团队形成之前提到的5个大的工作分类，每个分类都需要有专精的人才。这个时候系统运维更专注于基础设施的建设和运维，提供稳定、高效的网络环境，交付服务器等资源给应用运维工程师。应用运维更专注于服务运行状态和效率。数据库运维属于应用运维工作的细化，更专注于数据库领域的自动化、性能优化和安全防御。运维研发和运维安全提供各类平台、工具，进一步提升运维工程师的工作效率，使业务服务运行得更加稳定、高效和安全。
我们将运维发展过程划分为4个阶段，如图1-2所示。
图1-2 运维发展过程
手工管理阶段：业务流量不大，服务器数量相对较少，系统复杂度不高。对于日常的业务管理操作，大家更多的是逐台登录服务器进行手工操作，属于各自为战，每个人都有自己的操作方式，缺少必要的操作标准、流程机制，比如业务目录环境都是各式各样的。
工具批量操作阶段：随着服务器规模、系统复杂度的增加，全人工的操作方式已经不能满足业务的快速发展需要。因此，运维人员逐渐开始使用批量化的操作工具，针对不同操作类型出现了不同的脚本程序。但各团队都有自己的工具，每次操作需求发生变化时都需要调整工具。这主要是因为对于环境、操作的规范不够，导致可程序化处理能力较弱。此时，虽然效率提升了一部分，但很快又遇到了瓶颈。操作的质量并没有太多的提升，甚至可能因为批量执行而导致更大规模的问题出现。我们开始建立大量的流程规范，比如复查机制，先上线一台服务器观察10分钟后再继续后面的操作，一次升级完成后至少要观察20分钟等。这些主要还是靠人来监督和执行，但在实际过程中执行往往不到位，反而降低了工作效率。
平台管理阶段：在这个阶段，对于运维效率和误操作率有了更高的要求，我们决定开始建设运维平台，通过平台承载标准、流程，进而解放人力和提高质量。这个时候对服务的变更动作进行了抽象，形成了操作方法、服务目录环境、服务运行方式等统一的标准，如程序的启停接口必须包括启动、停止、重载等。通过平台来约束操作流程，如上面提到的上线一台服务器观察10分钟。在平台中强制设定暂停检查点，在第一台服务器操作完成后，需要运维人员填写相应的检查项，然后才可以继续执行后续的部署动作。
系统自调度阶段：更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立，原有的将批量操作转化成平台操作的方式已经不再适合，需要对服务变更进行更高一层的抽象。将每一台服务器抽象成一个容器，由调度系统根据资源使用情况，将服务调度、部署到合适的服务器上，自动化完成与周边各个运维系统的联动，比如监控系统、日志系统、备份系统等。通过自调度系统，根据服务运行情况动态伸缩容量，能够自动化处理常见的服务故障。运维人员的工作也会前置到产品设计阶段，协助研发人员改造服务使其可以接入到自调度系统中。
在整个运维的发展过程中，希望所有的工作都自动化起来，减少人的重复工作，降低知识传递的成本，使我们的运维交付更高效、更安全，使产品运行更稳定。对于故障的处理，也希望由事后处理变成提前发现，由人工处理变成系统自动容灾。
五、2018年Linux运维必须抓住的前沿技能
这是技术世界正在发生的深刻变革的冰山一角，那么问题来了? 作为传统的运维该如何转型呢?
这里给出一点小的建议: 大致需要学习下这四个部分:
- 自动化运维（Ansible，Puppet，Saltstack等）
- Devops（Docker，K8s，Jenkins，Jira等），
- 云服务技术（虚拟化、OpenStack、AWS及阿里云各种产品服务架构等）
- python
来源于马哥官网