在这些大类下面，还要细分各种小类，以技术为例，可分为前端（客户端）、后端、测试、运维、DBA等等，这些都是技术类岗位。
那么如果想从事这些技术岗位，该如何选择，哪一个更有前途呢？
这五个岗位，可以做一个分类，前端和后端、运维和DBA、测试
前端和后端属程序类，也就是通常大家知道的程序员，主要是根据产品的需求开发出软件，属于公司的技术核心，非常重要。没有程序员的软件公司，也不好意思称为软件公司。
运维和DBA，这两个岗位的主要工作是管理服务器程序运行的环境和依赖的数据。运维可以看成是服务器管理员，所有跟服务器相关工作都是由他处理，比如服务器程序运行环境CPU、内存、磁盘资源监控、网络是否稳定监控，服务器程序依赖的软件安装等等。DBA就是数据库管理员，专门管理生产环境的数据库如MySQL、Redis。这两个岗位的工资不一定比程序员低，但是市场需求没有程序员旺盛。一家软件公司可以没有运维和DBA，但是不能没有程序。运维和DBA一般只有上规模的企业配备，小公司都由程序员兼任，毕竟如果公司只有个位数的服务器，完全没有必要专门配备一个运维，老板也不愿意花这个钱。
测试，虽然也是技术岗位，但是我个人感觉他们的工作不和技术挂钩，他们的工作就是不断使用程序员开发出来的软件，找出其中的BUG和漏洞。与此同时，他们的另一项工作就是督促程序员干活，修BUG。
论这些岗位的技术含量，我觉得测试是最低的，低端的测试几乎没有技术门槛，只要有软件使用经验，基本上都能干干测试的活，毕竟只是用用软件找找BUG嘛，而程序和运维则不行，必须掌握基础的技术技能才能上岗。当然高端的测试另当别论，他们也可以牛逼到天上。
其次是运维，当然并不是说运维这个岗位没有技术含量，同样运维的技术含量也很高，只是通常情况下，程序员都会点运维的工作，装装环境，监控下服务器运行情况，都没什么问题。反过来，运维却不一定会程序员的工作。我觉得运维应该是脱胎与程序员，然后随着行业的发展，独立成为一个岗位，本质上还是依附与程序员。
最后则是程序，一个合格的程序员，不但要掌握程序员本职的技术，还需要会服务器运维的技术，比如自己搭建一个测试环境，这样的技能是必须的，所以对服务器必然要有较为深入的了解。同时需要会DBA的技术，通常DBA是在数据量巨大的情况下才会配备，大多数时候一家公司不需要DBA，DBA的工作的都由运维或者程序员兼职的。与此同时，程序员还需要测试技能，当程序员写出来一个程序时，免不了要进行自测，写测试用例等等，只有经过自己测试，才可以将功能提交给专门的测试人员进一步测试。
所以，对于这三类岗位，我觉得程序员的技术含量是最高的。
我们再来说说这些岗位的发展前景。
对于一个大公司来说，会有专门的研发部门、运维部门、测试部门，然后设有研发总监、运维总监、测试总监，这些领导在公司的身价不相上下，不存在谁压谁一头的情况。但是在小公司通常只有一个技术部，这个部门管辖所有技术类员工，包括程序、运维、测试，甚至有的公司还会包含设计人员。而技术部门的领导十有八九是程序员出身，几乎不太会是运维或测试出身。因为一个软件公司的技术部门，没有运维和测试，照样可以运转，虽然有可能转的不顺溜，但是一定可以转，但是没有程序员，即便运维和测试配备的多么强大，这个部门也转不起来。其次一个技术部门程序员的数量绝对是压制运维和测试人员数量的。因此在程序员中出技术部门领导的概率远大于在运维和测试中出领导，除非真的遇到难得一见的人才。
所以，如果你想从事互联网软件行业的技术岗位，要想选其中比较有前途的技术类岗位，那么首选程序员，当然，更多的机会也意味着有更大的竞争，同时也有更大的难度，你选择程序员不见得一定会成为技术部门的领导，选择测试和运维也不意味着职业生涯会默默无闻，只是相对来说程序员的情景更加明朗。
与此同时，关于35岁程序员会被淘汰的观点，其实运维和测试的危险性更大，仔细想想难道不是吗，运维和测试并没有比程序员更有优势，反而劣势一大堆，那么肯定比程序员先一步面对淘汰，这是市场规则。
对于一个开发人员来讲，可能运维并不是自己的职责所在。但是作为一名开发人员，却不能不了解自动化运维的整个流程。因为对于一个信息系统而言，开发和运维本质是一体的，尤其对于一些小公司来讲，可能运维人员本身就是开发人员抽空兼任的。
而自动化运维，本质上是介于开发和运维之间的，是运维和开发的交集，甚至很多时候都要写不少代码。因此，任何一个开发人员，都需要有自动化运维的相关知识。
一个了解好的开发人员，即使自己不做运维相关的工作，也能够知道自己在将项目交付给运维人员的时候，哪些东西是重要的，那些是必须配置的等等。然而在实际工作中，往往开发人员会给运维人员留下一些坑，一些只有他自己知道，而运维人员不知道的东西。导致运维人员自己试了很多次发现不行的时候，找到开发人员，开发人员研究了一下才会告诉他，在某某环境中必须用哪个端口之类的。这样不仅白白浪费了运维人员的时间，也增加了很多沟通的工作量。
反过来也是如此，一些现场的问题如果运维人员不能现场给出问题的定位。对于开发人员来讲是非常难以复现的。比如之前有某家企业，运维人员在客户现场发现问题。费了很大力气从客气的内网里面把日志导出来，发给开发人员，结果开发人员仔细研究了日志之后，发现是网不通的问题。开发人员显然是不可能知道为啥网不通的，搞不好是压根没连网线。
所以今天我们来聊一聊，对于一个程序员来讲，需要了解的自动化运维的那些事。
一、自动化运维的概念
随着信息时代的持续发展，初期的几台服务器已经发展成为了庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求。一个运维人员手工配置几台服务器还可能。配置几百上千台服务器那就累死了，还容易出错。那么就需要对运维工作进行标准化、自动化、架构优化、过程优化等。从面降低运维服务成本。其中，自动化最开始作为代替人工 *** 作为出发点的诉求被广泛研究和应用。
所谓自 动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统7*24小时高效稳定运行 。这是所有业务系统运维的终极目标。
按照运维的发展成熟度来看， 运维大致可分为三个阶段 ：
（1）依靠纯手工，重复地进行软件的部署与运维；
（2）通过编写脚本，方便地进行软件的部署与运维；
（3）借助第三方工具，高效地进行软件的部署与运维；
二、自动化运维需要解决的问题
自动化运维通常来讲，需要解决以下几个问题： 自动部署配置、风险事前预警、故障事中解决、和故障事后管理 。
三、自动化运维的常用工具
自动化运维常用的工具包括以下几种：
1、Ansible
ansible是基于Python开发的自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。
ansible具有如下一些特性：
(1)模块化：调用特定的模块，完成特殊的任务。
(2)Paramiko(python对ssh的实现)，PyYaml，jinja2(模块语言)三个关键模块。
(3)支持自定义模块，可使用任何编程语言写模块。
(4)基于python语言实现。
(5)部署简单，基于python和SSH(默认已安装)，agentless，无需代理不依赖KPI(无需SSL)。
(6)安全，基于OpenSSH
(7)幂等性：一个任务执行一次和执行n遍效果一样，不因重复执行带来意外情况。
(8)支持playbook编排任务，YAML格式，编排任务，支持丰富的数据结构。
(9)较强大的多层解决方案role。
2、Chef
Chef是一个功能强大的自动化工具，可以部署，修复和更新以及管理服务器和应用程序到任何环境。
Chef 主要分为三个部分 Chef Server、Workstation 以及 Chef Client。用户在 Workstation 上编写 Cookbook。然后，通过 knife 命令上传到 Chef Server。最后，在 Chef Client 上面实施安装和部署工作。所以，对于 Cookbook 地编写在整个自动化部署中起到了重要的作用。
Chef Server 包含所有配置数据，并存储描述Chef-Client中每个Nodes的Recipe，Cookbook和元数据。配置详细信息通过Chef-Client提供给Nodes。所做的任何更改都必须通过Chef Server进行部署。在推送更改之前，它通过使用授权密钥来验证Nodes和Workstations是否与服务器配对，然后允许Workstations和Nodes之间进行通信。
Workstations 用于与Chef-server进行交互，还用于与Chef-nodes进行交互。它还用于创建Cookbook。Workstations是所有交互发生的地方，在这里创建，测试和部署Cookbook，并在Workstations中测试代码。
Chef命令行工具 是创建，测试和部署Cookbook的地方，并通过此策略将其上载到Chef Server。
Knife 用于与ChefNodes进行交互。
Test Kitchen 用于验证Chef代码
Chef-Repo 是一个通过Chef命令行工具在其中创建，测试和维护Cookbook的存储库。
Nodes 由Chef管理，每个Nodes通过在其上安装Chef-Client进行配置。 ChefNodes 是一台机器，例如物理云，云主机等。
Chef-Client 负责注册和认证Nodes，构建Nodes对象以及配置Nodes。Chef-Client在每个Nodes上本地运行以配置该Nodes。
Cookbook 是Chef 框架的重要基础功能之一。在 Chef Server 对目标机器做安装部署的时候，是通过 Runlist。而 Runlist 里面又包含了一个一个具体的 Cookbook，所以，最终对一个目标机器的部署任务就落到了 Cookbook 上。而对于 Cookbook 来说，其中包含了多个组件，我们可以将 Cookbook 简单地理解成一个容器或者可以理解为一个包，里面包含了 recipes、files、templates、libraries、metadata 等信息。这些信息用于配置我们的目标机器。
3、Puppet
puppet是一种Linux、Unix平台的集中配置管理系统，所谓配置管理系统，就是管理其里面诸如文件、用户、进程、软件包等资源。它可以运行在一台服务器端，每个客户端通过SSL证书连接到服务端，得到本机器的配置列表，然后根据列表来完成配置工作，所以如果硬件性能比较高，维护管理上千上万台机器是非常轻松的，前提是客户端的配置、服务器路径、软件需要保持一致。
客户端Puppet会调用本地facter，facter探测出该主机的常用变量，例如主机名、内存大小、IP地址等。然后Puppetd把这些信息发送到Puppet服务端；
Puppet服务端检测到客户端的主机名，然后会检测manifest中对应的node配置，并对这段内容进行解析，facter发送过来的信息可以作为变量进行处理；
Puppet服务器匹配Puppet客户端相关联的代码才能进行解析，其他的代码不解析，解析分为几个过程，首先是语法检查，然后会生成一个中间的伪代码，之后再把伪代码发给Puppet客户端；
Puppet客户端接收到伪代码之后就会执行，执行完后会将执行的结果发送给Puppet服务器；
Puppet服务端再把客户端的执行结果写入日志。
4、Saltstack
SaltStack是基于python开发的一套C/S自动化运维工具。部署轻松，扩展性好，很容易管理上万台服务器，速度够快。与服务器之间的交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理，传输采用AES加密。
在saltstack架构中服务器端叫Master，客户端叫Minion。
在Master和Minion端都是以守护进程的模式运行，一直监听配置文件里面定义的ret_port(接受minion请求)和publish_port(发布消息)的端口。当Minion运行时会自动连接到配置文件里面定义的Master地址ret_port端口进行连接认证。
saltstack除了传统的C/S架构外，其实还有一种叫做masterless的架构，其不需要单独安装一台 master 服务器，只需要在每台机器上安装 Minion端，然后采用本机只负责对本机的配置管理机制服务的模式。
saltstack提供如下一些功能：
（1）远程执行：（批量执行命令）在master上执行命令时，会在所有的minion上执行。
（2）配置管理/状态管理 ：（描述想到达到的状态，saltstack就会去执行）
（3）云管理(cloud)：用于管理云主机
（4）事件驱动：被动执行，当达到某个值会自动触发
这四种自动化运维工具的比较如下，现在主流的基本上ansible和saltstack用的多一些：
对于大多数运维程序员来说，时时刻刻都需要关注服务器和系统程序可能出现的问题并提前解决。
今天我们就通过案例分析来了解一下，运维程序员如何快速处理线上问题。
任何一旦掉进坑里，明智的做法一定是：跳坑_>填坑_>避坑，线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下：跳坑‘跳坑’——快速恢复线上服务，或者将对线上服务的影响降到低。
线上服务的可用性决定着服务者的客户利益，影响着公司的收益。
一旦线上环境不可用，无法服务用户，给公司/团队带来经济利益损失的同时，更为严重的会给公司/团队带来恶劣的名声。
所以一般公司都会对线上环境提出稳定性和可靠性的要求，这也是团队乃至部门的kpi。
为此，遇到生产故障后的一要务是：恢复生产服务，即使不能完全恢复线上服务，也要想尽办法将对线上服务的影响降到低。
填坑‘填坑’——找到问题原因，根本上解决问题。
在恢复线上服务，尽大限度减掉对用户/公司/团队带来的影响后，我们需要彻查问题，搞清楚故障发生的根本原因，从根本上解决问题。
通常情况下，‘填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，或者服务降级/熔断等等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’。
避坑‘避坑’——举一反三，消灭隐患。
找到了根本原因，解决了问题之后，我们需要举一反三，以此及彼，想想在这个故障排查和处理过程中，那些环节存在弱点?那些流程/规范/制度需要优化?这类问题是否在其他系统或者团队中也存在?通过这样的反思和自我批评，形成一份线上事故报告，不断完善流程，避免再次踩坑，也在团队中交流经验，共同提高。
线上故障处理的思路依据线上故障处理的目标及目标的优先级，线上排障的一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，再行回溯总结，以便‘避坑’。
因此，可以将线上故障处理的步骤分为：故障发现故障定位故障排除故障回溯其中前三步是‘跳坑’行为，后面一步包含了‘填坑’和‘避坑’。
上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障，恢复服务。
这个思路类似于 *** 作系统的fork/join设计思想，目的在于提高效率。
在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务降级、服务器扩容等手段，确保对线上服务降到低且可控。
郑州北大青鸟http://www.kmbdqn.cn/建议可以等到线上服务’撑’过去之后，我们再慢慢定位故障原因，根本上解决问题。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）