互联⽹运维⼯作，以服务为中⼼，以稳定、安全、⾼效为三个基本点，确保公司的互联⽹业务能够 7×24 ⼩时为⽤户提供⾼质量的服务。 运维⼈员对公司互联⽹业务所依赖的基础设施、基础服务、线上业务进⾏稳定性加强，进⾏⽇常巡检发现服务可能存在的隐患，对整体架构进⾏优化以屏蔽常见的运⾏故障，多数据中接⼊提⾼业务的容灾能⼒。
通过监控、⽇志分析等技术⼿段，及时发现和响应服务故障，减少服务中断的时间，使公司的互联⽹业务符合预期的可⽤性要求，持续稳定地为⽤户提供务。
在安全⽅⾯，运维⼈员需要关注业务运⾏所涉及的各个层⾯，确保⽤户能够安全、完整地访问在线业务。
从⽹络边界划分、ACL 管理、流量分析、DDoS 防御，到操作系统、开源软件的漏洞扫描和修补，再到应⽤服务的XSS、SQL注⼊防护；从安全流程梳、代码⽩盒⿊盒扫描、权限审计，到⼊侵⾏为检测、业务风险控制等。 运维⼈员需要保障公司提供的互联⽹业 运⾏在安全、可控的状态下，确保公司业务数据和⽤户隐私数据
的安全，同时还需要具备抵御各种恶意攻击的能⼒。
在确保业务稳定、安全的前提下，还需保障业务⾼效的运转，公司内快速的产出。运维⼯作需要对业务进⾏各⽅⾯优化。
⽐如，IO 优化提升数据库性能，图⽚压缩降低带宽使⽤量等，提供的互联⽹业务以较⼩的资源投⼊带来最⼤的⽤户价值和体验。
同时，还需要通过各种⼯具平台提升内部产品发布交付的效率，提升公司内运维相关的⼯作效率。
⼯作分类运维
运维的⼯作⽅向⽐较多，随着业务规模的不断发展，越成熟的互联⽹公司，运维岗位会划分得越细。
当前很多⼤型的互联⽹公司，在初创时期只有系统运维，随着服务规模、服务质量的要求，也逐渐进⾏了⼯作细分。
⼀般情况下运维团队的⼯作分类和职责如下。
系统运维
系统运维负责IDC、⽹络、CDN和基础服务的建设（LVS、NTP、DNS）；负责资产管理，服务器选型、交付和维修。详细的⼯作职责如下。 1.IDC数据中⼼建设
收集业务需求，预估未来数据中⼼的发展规模，从⾻⼲⽹的分布，数据中⼼建筑，以及Internet接⼊、⽹络攻击防御能⼒、扩容能⼒、空间预留、外接专线能⼒、现场服务⽀撑能⼒等⽅⾯评估选型数据中⼼。负责数据中⼼的建设、现场维护⼯作。
2.⽹络建设
设计及规划⽣产⽹络架构，这⾥⾯包括：数据中⼼⽹络架构、传输⽹架构、CDN⽹络架构等，以及⽹络调优等⽇常运维⼯作。
3.LVS 负载均衡和 SNAT 建设
LVS 是整个站点架构中的流量⼊⼝，根据⽹络规模和业务需求，构建负载均衡集。完成⽹络与业务服务器的衔接，提供⾼性能、⾼可⽤的负载调度能⼒，以及统⼀的⽹络层防攻击能⼒。SNAT .集中提供数据中⼼的公⽹访问服务，通过集化部署，保证出⽹服务的⾼性能与⾼可⽤。
4.CDN 规划和建设
CDN ⼯作划分为第三⽅和⾃建两部分。建⽴第三⽅ CDN 的选型和调度控制；根据业务发展趋势，规划CDN新节点建设布局；完善CDN业务及监控，保障CDN 系统稳定、⾼效运⾏。分析业务加速频道的⽂件特性和数量，制定最优的加速策略和资源匹配；负责⽤户劫持等CDN ⽇常故障排查⼯作。
5.服务器选型、交付和维护
负责服务器的测试选型，包含服务器整机、部件的基础性测试和业务测试，降低整机功率，提升机架部署密度等。
结合对公司业务的了解，推⼴新硬件、新⽅案减少业务的服务器投⼊规模。负责服务器硬件故障的诊断定位，服务器硬件监控、健康检查⼯具的开发和维护。
6.OS、内核选型和 OS 相关维护⼯作
负责整体平台的 OS 选型、定制和内核优化，以及 Patch 的更新和内部版本发布；建⽴基础的YUM包管理和分发中⼼，提供常⽤包版本库；跟进⽇常各类 OS 相关故障；针对不同的业务类型，提供定向的优化⽀持。
7.资产管理
记录和管理运维相关的基础物理信息，包括数据中⼼、⽹络、机柜、服务器、ACL、IP等各种资源信息，制定有效的流程，确保信息的准确性；开放API接⼝，为⾃动化运维提供数据⽀持。
8.基础服务建设
业务对 DNS、NTP、SYSLOG 等基础服务的依赖⾮常⾼，需要设计⾼可⽤架构避免单点，提供稳定的基础服务。
应⽤运维
应⽤运维负责线上服务的变更、服务状态监控、服务容灾和数据备份等⼯作，对服务进⾏例⾏排查、故障应急处理等⼯作。详细的⼯作职责如下所述。
1.设计评审
在产品研发阶段，参与产品设计评审，从运维的⾓度提出评审意见，使服务满⾜运维准⼊的⾼可⽤要求。
2.服务管理
负责制定线上业务升级变更及回滚⽅案，并进⾏变更实施。掌握所负责的服务及服务间关联关系、服务依赖的各种资源。能够发现服务上的缺陷，及时通报并推进解决。制定服务稳定性指标及准⼊标准，同时不断完善和优化程序和系统的功能、效率，提⾼运⾏质量。完善监控内容，提⾼报警准确度。在线上服务出现故障时，第⼀时间响应，对已知线上故障能按流程进⾏通报并按预案执⾏，未知故障组织相关⼈员联合排障。
3.资源管理
对各服务的服务器资产进⾏管理，梳理服务器资源状况、数据中⼼分布情况、⽹络专线及带宽情况，能够合理使⽤服务器资源，根据不同服务的需求，分配不同配置的服务器，确保服务器资源的充分利⽤。
4.例⾏检查
制定服务例⾏排查点，并不断完善。根据制定的服务排查点，对服务进⾏定期检查。对排查过程中发现的问题，及时进⾏追查，排除可能存在的隐患。
5.预案管理
确定服务所需的各项监控、系统指标的阈值或临界点，以及出现该情况后的处理预案。建⽴和更新服
务预案⽂档，并根据⽇常故障情况不断补充完善，提⾼预案完备性。能够制定和评审各类预案，周期性进⾏预案演练，确保预案的可执⾏性。
6.数据备份
制定数据备份策略，按规范进⾏数据备份⼯作。保证数据备份的可⽤性和完整性，定期开展数据恢复性测试。
数据库运维
数据库运维负责数据存储⽅案设计、数据库表设计、索引设计和SQL优化，对数据库进⾏变更、监控、备份、⾼可⽤设计等⼯作。详细的⼯作职责如下所述。
1.设计评审
在产品研发初始阶段，参与设计⽅案评审，从DBA的⾓度提出数据存储⽅案、库表设计⽅案、SQL开发标准、索引设计⽅案等，使服务满⾜数据库使⽤的⾼可⽤、⾼性能要求。
2.容量规划
掌握所负责服务的数据库的容量上限，清楚地了解当前瓶颈点，当服务还未到达容量上限时，及时进⾏优化、分拆或者扩容。
3.数据备份与灾备
制定数据备份与灾备策略，定期完成数据恢复性测试，保证数据备份的可⽤性和完整性。
4.数据库监控
完善数据库存活和性能监控，及时了解数据库运⾏状态及故障。数据库安全建设数据库账号体系，严格控制账号权限与开放范围，降低误操作和数据泄露的风险；加强离线备份数据的管理，降低数据泄露的风险。
5.数据库⾼可⽤和性能优化
对数据库单点风险和故障设计相应的切换⽅案，降低故障对数据库服务的影响；不断对数据库整体性能进⾏优化，包括新存储⽅案引进、硬件优化、⽂件系统优化、数据库优化、SQL优化等，在保障成本不增加或者少量增加的情况下，数据库可以⽀撑更多的业务请求。
6.⾃动化系统建设
设计开发数据库⾃动化运维系统，包括数据库部署、⾃动扩容、分库分表、权限管理、备份恢复、SQL审核和上线、故障切换等功能。
7.运维研发
运维研发负责通⽤的运维平台设计和研发⼯作，如：资产管理、监控系统、运维平台、数据权限管理系统等。提供各种API供运维或研发⼈员使⽤，封装更⾼层的⾃动化运维系统。详细的⼯作职责如下所述。
8.运维平台
记录和管理服务及其关联关系，协助运维⼈员⾃动化、流程化地完成⽇常运维操作，包括机器管理、重启、改名、初始化、域名管理、流量切换和故障预案实施等。
9.监控系统
负责监控系统的设计、开发⼯作，完成公司服务器和各种⽹络设备的资源指标、线上业务运⾏指标的收集、告警、存储、分析、展⽰和数据挖掘等⼯作，持续提⾼告警的及时性、准确性和智能性，促进公司服务器资源的合理化调配。
10.⾃动化部署系统
参与部署⾃动化系统的开发，负责⾃动化部署系统所需要的基础数据和信息，负责权限管理、API开发、Web端开发。结合云计算，研发和提供PaaS相关⾼可⽤平台，进⼀步提⾼服务的部署速度和⽤户体验，提升资源利⽤率。
运维安全
运维安全负责⽹络、系统和业务等⽅⾯的安全加固⼯作，进⾏常规的安全扫描、渗透测试，进⾏安全⼯具和系统研发以及安全事件应急处理。详细的⼯作职责如下所述。
1.安全制度建⽴
根据公司内部的具体流程，制定切实可⾏，且⾏之有效的安全制度。
2.安全培训
定期向员⼯提供具有针对性的安全培训和考核，在全公司内建⽴安全负责⼈制度。
3.风险评估
通过⿊⽩盒测试和检查机制，定期产⽣对物理⽹络、服务器、业务应⽤、⽤户数据等⽅⾯的总体风险评估结果。
4.安全建设
根据风险评估结果，加固最薄弱的环节，包括设计安全防线、部署安全设备、及时更新补丁、防御病毒、源代码⾃动扫描和业务产品安全咨询等。为了降低可能泄露数据的价值，通过加密、匿名化、混淆数据，乃⾄定期删除等技术⼿段和流程来达到⽬的。
5.安全合规
为了满⾜例如⽀付牌照等合规性要求，安全团队承担着安全合规的对外接⼝⼈⼯作。
6.应急响应
建⽴安全报警系统，通过安全中⼼收集第三⽅发现的安全问题，组织各部门对已经发现的安全问题进⾏修复、影响⾯评估、事后安全原因追查。运维⼯作发展过程
早期的运维团队在⼈员较少的情况下，主要是进⾏数据中⼼建设、基础⽹络建设、服务器采购和服务器安装交付⼯作。⼏乎很少涉及线上服务的变更、监控、管理等⼯作。
这个时候的运维团队更多的属于基础建设的⾓⾊，提供⼀个简单、可⽤的⽹络环境和系统环境即可。
随着业务产品的逐渐成熟，对于服务质量⽅⾯就有了更⾼的要求。这个时候的运维团队还会承担⼀些服务器监控的⼯作，同时会负责LVS、Nginx 等与业务逻辑⽆关的 4/7 层运维⼯作。
这个时候服务变更更多的是逐台的⼿⼯操作，或者有⼀些简单批量脚本的出现。监控的焦点更多的在服务器状态和资源使⽤情况上，对服务应⽤状态的监控⼏乎很少，监控更多的使⽤各种开源系统如Nagios、Cacti等。
由于业务规模和复杂度的持续增加，运维团队会逐渐划分为应⽤运维和系统运维两⼤块。应⽤运维开始接⼿线上业务，逐步开展服务监控梳理、数据备份以及服务变更的⼯作。
随着对服务的深⼊，应⽤运维⼯程师有能⼒开始对服务进⾏⼀些简单的优化。同时，为了应对每天⼤量的服务变更，我们也开始编写各类运维⼯具，针对某些特定的服务能够很⽅便的批量变更。
随着业务规模的增⼤，基础设施由于容量规划不⾜或抵御风险能⼒较弱导致的故障也越来越多，迫使运维⼈员开始将更多的精⼒投⼊到多数据中⼼容灾、预案管理的⽅向上。
业务规模达到⼀定程度后，开源的监控系统在性能和功能⽅⾯，已经⽆法满⾜业务需求；⼤量的服务变更、复杂的服务关系，以前靠⼈⼯记录、⼯具变更的⽅式不管在效率还是准确性⽅⾯也都⽆法满⾜业务需求。
在安全⽅⾯也出现了各种⼤⼤⼩⼩的事件，迫使我们投⼊更多的精⼒在安全防御上。逐渐的，运维团队形成之前提到的5个⼤的⼯作分类，每个分类都需要有专精的⼈才。
这个时候系统运维更专注于基础设施的建设和运维，提供稳定、⾼效的⽹络环境，交付服务器等资源给应⽤运维⼯程师。应⽤运维更专注于服务运⾏状态和效率。
数据库运维属于应⽤运维⼯作的细化，更专注于数据库领域的⾃动化、性能优化和安全防御。运维研发和运维安全提供各类平台、⼯具，进⼀步提升运维⼯程师的⼯作效率，使业务服务运⾏得更加稳定、⾼效和安全。
我们将运维发展过程划分为4个阶段：
⼿⼯管理阶段：业务流量不⼤，服务器数量相对较少，系统复杂度不⾼。对于⽇常的业务管理操作，⼤家更多的是逐台登录服务器进⾏⼿⼯操作，属于各⾃为战，每个⼈都有⾃⼰的操作⽅式，缺少必要的操作标准、流程机制，⽐如业务⽬录环境都是各式各样的。
⼯具批量操作阶段：随着服务器规模、系统复杂度的增加，全⼈⼯的操作⽅式已经不能满⾜业务的快速发展需要。因此，运维⼈员逐渐开始使⽤批量化的操作⼯具，针对不同操作类型出现了不同的脚本程序。
但各团队都有⾃⼰的⼯具，每次操作需求发⽣变化时都需要调整⼯具。这主要是因为对于环境、操作的规范不够，导致可程序化处理能⼒较弱。此时，虽然效率提升了⼀部分，但很快⼜遇到了瓶颈。
操作的质量并没有太多的提升，甚⾄可能因为批量执⾏⽽导致更⼤规模的问题出现。我们开始建⽴⼤量的流程规范，⽐如复查机制，先上线⼀台服务器观察10分钟后再继续后⾯的操作，⼀次升级完成后⾄少要观察20分钟等。
这些主要还是靠⼈来监督和执⾏，但在实际过程中执⾏往往不到位，反⽽降低了⼯作效率。
平台管理阶段：在这个阶段，对于运维效率和误操作率有了更⾼的要求，我们决定开始建设运维平台，通过平台承载标准、流程，进⽽解放⼈⼒和提⾼质量。
这个时候对服务的变更动作进⾏了抽象，形成了操作⽅法、服务⽬录环境、服务运⾏⽅式等统⼀的标准，如程序的启停接⼝必须包括启动、停⽌、重载等。通过平台来约束操作流程，如上⾯提到的上线⼀台服务器观察10分钟。
在平台中强制设定暂停检查点，在第⼀台服务器操作完成后，需要运维⼈员填写相应的检查项，然后才可以继续执⾏后续的部署动作。
系统⾃调度阶段：更⼤规模的服务数量、更复杂的服务关联关系、各个运维平台的林⽴，原有的将批量操作转化成平台操作的⽅式已经不再适合，需要对服务变更进⾏更⾼⼀层的抽象。
将每⼀台服务器抽象成⼀个容器，由调度系统根据资源使⽤情况，将服务调度、部署到合适的服务器上，⾃动化完成与周边各个运维系统的联动，⽐如监控系统、⽇志系统、备份系统等。
通过⾃调度系统，根据服务运⾏情况动态伸缩容量，能够⾃动化处理常见的服务故障。运维⼈员的⼯作也会前置到产品设计阶段，协助研发⼈员改造服务使其可以接⼊到⾃调度系统中。
在整个运维的发展过程中，希望所有的⼯作都⾃动化起来，减少⼈的重复⼯作，降低知识传递的成本，使我们的运维交付更⾼效、更安全，使产品运⾏更稳定。对于故障的处理，也希望由事后处理变成提前发现，由⼈⼯处理变成系统⾃动容灾。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议