怎样才能学好Linux运维

自学或者系统培训都可以，自学周期长，不成体系，遇到问题没有及时解答，很容易放弃；系统培训，有教练专门教你，这些问题很容易解答；
1） Linux运维岗位及工作内容
互联网Linux运维工程师是一个融合多学科(网络、系统、开发、数据库、安全、存储等)的综合性技术岗位，甚至还需要沟通、为人处世、培训、销售、管理等非技术能力，这给运维工程师提供了一个广阔的发展空间。
2) Linux运维工程师岗位职责
一般从企业入门到中级Linux运维工程师的工作大致有：挑选IDC机房及带宽、购买物理服务器或云服务、购买及使用CDN服务、搭建部署程序开发及用户的访问系统环境(例如:网站运行环境)、对数据进行备份及恢复、处理网站运行中的各种故障（例如：硬件故障、软件故障、服务故障、数据损坏及丢失等）、对网站的故障进行监控、解决网站运行的潜在安全问题、开发自动化脚本程序提高工作效率、规划网站架构、程序发布流程和规范，制定运维工作制度和规范、配合开发人员部署及调试产品研发需要的测试环境、代码发布等工作需求，公司如果较小可能还会兼职网管、网络工程师、数据库管理员、安全工程师、技术支持等职责。
涉及到的Linux平台上的运维工具有：Linux系统,Linux基础命令,Nginx,Apache,MySQL,PHP,Tomcat,Lvs,Keepalived,SSH,Ansible,Rsync,NFS,Inotify,Sersync,Drbd,PPTP,Open,NTP,Kickstart/Cobbler,KVM,OpenStack,Docker,，K8S，Mongodb,Redis,Memcached,Iptables,SVN,GIT,Jenkins,网络基础,Shell/Python开发基础等，除此之外还可能涉及到交换机、路由器、存储、安全、开发等知识。
运维工程师还包括一些低端的岗位，例：网络管理员、监控运维、IDC运维，值班运维
职业发展方向：Linux运维工程师、系统架构师、数据库工程师、运维开发工程师、系统网络安全工程师、运维经理、运维总监
3) Linux中级运维工程师应用软件阶段。
Linux系统,Linux基础命令,Nginx,Apache,MySQL,PHP,Tomcat,Lvs,Keepalived,SSH,Ansible,Rsync,NFS,Inotify,Sersync,Drbd,PPTP,Open,NTP,Kickstart/Cobbler,KVM,OpenStack,Docker,Mongodb,Redis,Memcached,Iptables,SVN,GIT,Jenkins,网络基础,Shell/Python开发基础
4)Linux运维架构师岗位职责
运维架构师是运维工程师的高级阶段，并没有明确的岗位界限区分，运维架构师一般来说是除了对运维工程师应用的开源工具熟练掌握之外，更多的是用思想来运维了，即DevOps的落地，各种企业运行过程中的解决方案提出和执行，例如：根据公司的现状可以设计各类运维解决方案的能力：
1、自动化代码上线（SVN/GIT+Jenkins+MVN）解决方案；
2、云计算部署架构及Docker微服务架构方案；
3、服务自动化扩容方案（KVM/OpenStack/Docker+Ansible+Zabbix）；
4、10万并发的网站架构、秒杀系统的架构及解决发你个案；
5、多IDC机房互联方案、全网数据备份解决方案、账号统一认证方案；
6、数据库、存储及各重要服务节点的集群和高可用方案。
7、各网络服务的极端优化方案、服务解耦/拆分。
8、运维流程、制度、规范等的建设和推行。
9、沟通能力、培训能力、项目管理、业务需求分析及落地执行力等。
这里仅举几个例子，实际工作中会有更多，运维架构师的工作，其实就是解决企业中的用户访问量不断增大带来的痛点，最终达到高效、优质的为客户提供网站及业务服务。
总的来说：Linux运维架构师更多的是根据企业日益增长的访问量需求，利用若干运维工具组合加上经验思想，形成解决业务需求方案的阶段，当然也不排除对运维工具进行二次开发以及可视化展示运维数据的阶段（开发软件平台），这个阶段涉及的工具会非常多，几乎市面好用的开源工具都在备选之列，在一线城市互联网公司的薪资范围15000-50000/月。
职业方向：高级数据库工程师、运维开发工程师、运维经理、运维总监、技术总监
运维架构师：将多个工具组合，加上思想经验，形成方案，用思想和经验赚钱的阶段。
技术的提升仅是量的积累，思想的提升才是质的飞跃！——老男孩
5)数据库运维工程师
众所周知，数据几乎是所有企业的生命线，所以数据库工程师的地位和薪水一般会比普通运维工程师高一些，主要工作内容就是保证数据库数据的安全以及高效地为用户提供各种服务。工作内容主要有：数据库环境搭建、数据库优化、数据库

1 *** 作系统状态监控
每天登陆系统查看系统运行的负荷如何，有无报错日志或报警日志。
2 *** 作系统故障排除
依据 *** 作系统故障日志分析出现该报警或报错的原因，从而解决问题，保证 *** 作系统的高可用性。
3服务器状态确认
服务器上除了跑着 *** 作系统，必然会安装一些应用程序或数据库，运维工程师每天需要查看linux系统上运行着的应用程序或数据库状态是否正常。
4备份
运维工程师的看家本事，数据库备份和恢复，一般来说只要给数据库制定了备份策略它会自己备份，你只需要监控备份任务是否执行了就可以。
5服务器调优
这个要求就比较高了，linux随着使用时间的增长，状态会有所下降，运维工程师有能力的可以对 *** 作系统及数据库进行性能调优，保证系统处于一个最佳状态。
一般来说，运维工程师的工作以监控为主，出现问题的时候才会进行处理，平时来说还是很轻松的。我负责着三个信息系统的六台服务器运维，挺轻松。

云服务器以简单、高效、安全、可靠、d性强等特性被越来越多的用户追崇，对于云服务器主要承载几个侧面的工作，功能层面：为企业提供IaaS层硬件资源，包含数据的分布式存储、分布式计算等；资源层面：提供资源整合动态管理，为PaaS层面提供相关资源共享服务，对比物理服务器而言对于企业用户无需提前购买自身的固态应用服务器硬件而是以按年缴费的模式进行云服务器的租赁，尽管云服务器一方面有效降低了IT的运维成本，但同时企业的核心数据也对外暴露存在数据安全的隐患。

伴随现在企业上云成为趋势，越来越多的应用软件提出自己的云领域软件平台如：明源云、泛微云、金蝶云等，为解决数据暴露的安全隐患云服务器也由原有的公有云衍生出私有云、混合云等多种形态，但伴随云形态的演进，“云孤岛、云竖井”也随之而来，对于企业用户而言原有的信息竖井并没有因为上云得到根本解决，因此能够实现云间集成、云到端、端到端无缝连接融合的中间集成平台是企业上云后的迫切需求，从而避免企业上云后云孤岛、云竖井的情况发生。

综上：云服务器确实能够灵活适配、d性伸缩有效解决IT服务器运维管理的难度，但企业上云的同时需要理智面对、选择，不要盲目跟风，同时兼顾云间集成整合、数据对接的模式及标准管理，避免仅仅是将物理应用转换部署模式而不是从根本解决企业的实际数据管控述求。

运维一般是指对大型组织已经建立好的网络软硬件的维护，其中传统的运维是指信息技术运维（IT运维）。随着信息化进程的推进，运维管理将覆盖对整个组织运行，进行支持的管理信息系统涵盖的所有内容，除了传统的IT运维，还拓展了业务运维和日常管理运维。其参与的对象也从IT部门和人员，拓展到组织的管理层和各部门，及其相关的业务骨干。
1　IT运维
IT运维是IT管理的核心和重点部分，也是内容最多、最繁杂的部分，该过程主要用于IT部门内部日常运营管理，其涉及的对象分成两大部分，即IT业务系统和运维人员；业务运维是业务需求和用户体验的核心和重点部分，更是需要对内容繁杂、持续变化、支持不同的业务需求，加以描述、加载和维护的过程，其涉及的对象包括2类人员，一类是提供业务支持的技术人员，另一类是整个组织的管理层和业务骨干，随着业务运维环境和工具的能力提升，功能完善、体验优化，技术人员将逐步退出这个领域；日常管理运维则是对IT运维和业务运维需求、过程、结果的管控，以及对整个管理信息系统运行状态的管控，从而实现针对应用变化的记录和跟踪、针对地域不同的变更和跟踪、预测环境和应用的风险和防范管理等等，其涉及的对象主要是运维管理部门的管理人员和参与人员。
2　业务运维
包含对企业自身核心业务系统运行情况的监控与管理，对于业务的管理，主要关注该业务系统的CSF（关键成功因素Critical Success Factors）和KPI（关键绩效指标Key Performance Indicators）。
3　日常管理运维
该部分主要用于规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决经验与知识的积累与共享手段IT运行维护管理的每一个子系统中都包含着十分丰富的内容，实现完善的IT运维管理是企业提高经营水平和服务水平的关键。运行/维护阶段与服务/支持阶段的分界线为前者是面向 IT部门内部的管理，而后者是面向业务部门、企业中的其它人员或直接面向客户。

参考资料：

>在企业内部也是一样，当大量的生产和经营数据集中在数据中心，一旦人们与数据中心因为IT故障而失去联系，停滞的也许不是个人应用受阻这样简单的后果。为了应对大数据下的新业务需求，传统的IT运维管理就需要针对数据中心基础架构做出改变，这种进化包括针对虚拟化和服务交付能力的调整，以及IT与业务融合所必备的方法和工具。 数据中心迎来了“按需配置”的变革 过去，每次当我们的数据中心的业务容量不足的时候，就会想到增加更多的硬件、设备来满足客户需求。但在海量数据汹涌来袭的时候，这种增加都是被动的、延迟的。据统计，互联网上的数据每两年翻一番，而目前世界上90%以上的数据都是最近几年才产生的，这为大数据概念的横空出世做好了准备。数据的增长超出了我们的预期，那么是否可以找到一个办法，让我们可以对业务部门提供一种“按需分配”的低成本方案呢？虚拟化技术以其降低成本、灵活性，以及动态的扩容特性，给出了最佳的答案。 许多企业希望采用云计算和虚拟化技术实现“按需配置”的基础环境、服务等级，实现更低的成本和更高的盈利。然而，要从大数据这个藏量巨大的金矿中淘到金子，并没那么容易，传统架构下的IT运维管理与成熟的虚拟化技术并没有齐头并进。 首先，虚拟机一旦出现故障，如果不能及时恢复，这个损失可能远远超过节省电源和空间的费用。其次，虚拟机的灵活性对IT运维中的“配置管理”可谓是一杯毒酒，泛滥的迁移和扩容会让IT基础设备重新回到混乱的过去。在传统数据中心，管理员可以确定地表述：我的数据库在服务器A上运行，这台服务器与交换机B进行连接并使用存储阵列C，它们的性能指标都非常良好。但动态数据中心采用虚拟化技术后，解耦了这种关系，更具伸缩性，或是随意的（人们对“灵活性”的误读）利用这些基础设施资源。业务系统可以位于服务器集群中的任何计算节点上，可以利用任何存储设备上的存储空间，可以使用虚拟网络，也可以进行转移以满足性能或运营需求。但这些优势，却在IT运维管理中造成“看不见”、“说不清”的严重问题。 虚拟化运维管理的“两大难题”如何突破？ 如果你都不知道自己的IT环境里有什么，就别指望控制、维护和提高它们。因此，配置管理和性能监控在任何时候都没有变，它们只是进化到了更高的阶段。 作为国内领先的IT运维管理专家，北塔软件认为：IT运维管理不是一蹴而就的，更不是一成不变的，大数据情形下的网络管理将要应对更多的技术和管理层面的挑战。之前，针对基础设施的监控一般侧重对物理设备、物理网络、物理存储的管理，而虚拟化后的变更 *** 作变得越来越简单，但这会使得一些虚拟机脱离管理的范围，尤其是在配置管理和性能监控两个方面。管理人员需要对新增的虚拟网络、数据存储、虚拟机、ESX/ESXi主机数量、集群对象提供一种与之配套的IT运维管理工具。 从改进配置管理开始着手是很重要的一步，因为这可以清晰地呈现出不断变化的虚拟机、物理服务器、存储和网络资源之间的关系。另外，随着每台物理机上托管的虚拟机数量增多并提高了整体利用率，性能测算与监控的重要性也在攀升。为了预防虚拟机密度过大，或者利用率不足的问题（虚拟化之后，这个问题并没有完全消除），运维管理人员必须拥随时调整物理主机的承载力。 为了消除用户大数据时代的运维顾虑，在全面提供了对主机、网络、机房等领域的管理解决方案之后，北塔软件在北塔BTIM（BetasoftIntegratedManagement，IT综合管理软件）中增加了针对VMware虚拟化管理和FC-SAN存储管理解决方案。

日常工作中需要大量、频繁地使用ssh到服务器查看、拉取相关的信息或者对服务器进行变更。目前公司大量使用的shell，但是随着逻辑的复杂化、脚本管理的精细化，shell已经不满足日常需求，于是我尝试整合工作中的需求，制作适合的工具。 由于管理制度的缺陷，我以工作流程为核心思考适合自己的运维方式，提升工作效率，把时间留给更有价值的事情。 完整代码在最后，请大家参考。

生产：4000+物理服务器，近 3000 台虚拟机。

开发环境：python36、redhat79，除了paramiko为第三方模块需要自己安装，其他的直接import即可。

批量执行 *** 作是一把双刃剑。批量执行 *** 作可以提升工作效率，但是随之而来的风险不可忽略。

风险案例如下：

挂载很多数据盘，通常先格式化硬盘，再挂载数据盘，最后再写入将开机挂载信息写入/etc/fstab文件。在批量lsblk检查硬盘信息的时候发现有的系统盘在/sda有的在/sdm，如果不事先检查机器相关配置是否一致直接按照工作经验去执行批量 *** 作，会很容易造成个人难以承受的灾难。

在执行批量 *** 作时按照惯例：格式化硬盘->挂载->开机挂载的顺序去执行，假设有的机器因为某些故障导致格式化硬盘没法正确执行。在处理这类问题的时候通常会先提取出失败的ip，并再按照惯例执行 *** 作。运维人员会很容易忽略开机挂载的信息已经写过了，导致复写（这都是血和泪的教训）。

所以，为了避免故障，提升工作效率，我认为应当建立团队在工作上的共识，应当遵守以下原则：

当然，代码的规范也应当重视起来，不仅是为了便于审计，同时也需要便于溯源。我认为应当注意以下几点：

1、ssh no existing session，sftp超时时间设置:

在代码无错的情况下大量ip出现No existing session，排查后定位在代码的写法上，下面是一个正确的示例。由于最开始没考虑到ssh连接的几种情况导致了重写好几遍。另外sftp的实例貌似不能直接设置连接超时时间，所以我采用了先建立ssh连接再打开sftp的方法。

2、sftp中的get()和put()方法仅能传文件，不支持直接传目录：

不能直接传目录，那换个思路，遍历路径中的目录和文件，先创建目录再传文件就能达到一样的效果了。在paramiko的sftp中sftplistdir_attr()方法可以获取远程路径中的文件、目录信息。那么我们可以写一个递归来遍历远程路径中的所有文件和目录(传入一个列表是为了接收递归返回的值)。

python自带的os模块中的oswalk()方法可以遍历到本地路径中的目录和文件。

3、多线程多个ip使用sftpget()方法时无法并发。

改成多进程即可。

4、多个ip需要执行相同命令或不同的命令。

由于是日常使用的场景不会很复杂，所以借鉴了ansible的playbook，读取提前准备好的配置文件即可，然后再整合到之前定义的ssh函数中。

同时，我们还衍生出一个需求，既然都要读取配置，那同样也可以提前把ip地址准备在文件里。正好也能读取我们返回的执行程序的结果。

参数说明：

密码认证：

公钥认证：

可以配合 grep，awk 等命令精准过滤。

个人认为 Python 在初中级运维工作中的性质更像是工具，以提升工作效率、减少管理成本为主。可以从当前繁琐的工作中解脱出来，去 探索 更有价值的事情。python 本质上并不会减少故障的产生，所以在不同的阶段合理利用自身掌握的知识解决当前最重要的痛点，千万不要本末倒置。

物理服务器（PhysicalServers）

指实实在在、存在的硬件专用独立主机或服务器设备，性能和稳定性都比较强，因此，价格也相对比较昂贵，需要用户自己根据需求进行配置、管理及运维。简单来说，物理服务器可以把它理解为一台“电脑”，实际上所有网站的程序都在这个“电脑”上运行。

云服务器（CloudServers）

指通过虚拟化技术将一台独立服务器虚拟成多个小的服务器，每个云服务器的运行和管理都完全独立，具有单独的 *** 作系统，可分配独立公网IP地址、超大磁盘、 *** 作系统Windows/Linux、内存、CPU资源等，网站运行环境和空间安全都需要用户自己去配置，对用户的技术能力有一定要求的。

云服务器是云计算服务的重要组成部分，是面向各类互联网用户提供综合业务能力的服务平台。平台整合了传统意义上的互联网应用三大核心要素：计算、存储、网络，面向用户提供公用化的互联网基础设施服务。

物理服务器VS云服务器

成本优化

物理服务器而言，无论用还是不用，设备就在那里，成本就在那里，照样算钱！

云服务器遵循按需购买，按照使用量付费的原则，具有成本低、d性伸缩、管理便捷等特点。

服务优化

物理服务器服务常规指实体服务器托管和租用两种服务类型，实体服务器托管是由用户自行购买硬件发往机房托管，期间设备的监控和管理工作均由用户单方独立完成，IDC数据中心提供IP接入、带宽接入、电力供应和网络维护等，租用是由IDC数据中心租用实体设备给客户使用，同时负责环境的稳定，用户无需购买硬件设备；

云服务器服务是指是从基础设施(Iaas)到业务基础平台(PaaS)再到应用层(SaaS)的连续的整体的全套服务，IDC数据中心将规模化的硬件服务器整合虚拟到云端，为用户提供的是服务能力和IT效能。

相较传统IDC服务模式，云计算IDC增值服务是相关于传统IDC增值服务的升级，是云计算数据中心下对传统IDC服务的升级版！云计算IDC情况下，可获得具备高扩展性和高可用的计算能力，用户也再无需担心硬件设备的性能限制等带来的问题。

资源优化

物理服务器，在硬件服务器的基础进行有限的整合，例如多台虚拟机共享一台实体服务器性能。

云服务器可通过资源集约化实现的动态资源调配，云计算可以实现横向/纵向的d性资源扩展和快速调度，传统IDC提供的资源难以承受短时间内的快速再分配，且不说企业等待的时间成本，本身而言容易造成资源闲置和浪费！

云服务器而言，通过更新的技术实现资源的快速再分配，可以在数分钟甚至几十秒内分配资源实现快速可用，可以有效地规避资源闲置的风险。此外，传统IDC远不如云计算IDC那样可以跨实体服务器，甚至实现跨数据中心的大规模有效整合。

效率优化

云计算IDC服务相较传统IDC服务，前者采取更加灵活的资源利用方式，通过技术提升和优化使用户从硬件设备的管理和运维工作中解脱出来，专注内部业务的开发和创新，由云服务商负责云平台本身的稳定，通过这种责任分担模式使整个平台的运行效率获得提升！

售后优化

首先，云服务器归于基本电信增值服务，所以其服务提供商需要获得工信部的批阅以具有相应的运营资质。云服务商对国家方针政策的了解，备案等业务流程的支持，也是确保客户可以合法合规的运营。再者，当服务器使用过程出现问题时，需要运营商的协助才可以解决，这种情况需要任何时候都可以找到主机商的售后支持，大多数云服务商而言都会提供724小时的云服务器售后支持服务，这点也可以打消用户的使用顾虑，让用户安心、放心！

---