1、做运维需要考虑的事
1.1 简介
/*
运维是在于一个量
最少的人，最多的事 并且保证业务
比如说google的一个数据中心，只有几个人在维护
运维不能直接的创造价值，而是可以变相的节约成本
你节约的成本x你的意识x你的觉悟=你的价值
———-来自 98素辞
*/
1.2 服务来说
1.2.1
对服务版本的选择要和开发沟通好，如果开发用的php，需要了解代码是哪个版本的，不同版本可能不兼容一些语法，会导致出错；
服务版本要选择稳定版，太新的可能会导致一些bug，从而导致崩溃或服务出错。选择新版本唯一的目的应该是需要新的功能，否则老的版本最稳定；
服务部署后要进行简单测试，让服务可以照常运行才可以，不能装完就算了。对于java替换版本，1.7升级到1.8可能导致某些依赖1.7的JDK有问题，这都要去考虑清楚。
当服务运行后要注意他的启动用户是什么，可能用户不对造成无法读取文件。比如Nginx启动使用www用户，就无法读取/data里的数据发送给用户。
数据库如果要和库，要考虑是否有表名字重复。如果公用一个redis进行缓存，要考虑写入的数据是否冲突。
1.2.2
根据业务进行结构分析，是使用Nginx还是Apache，选择前填写调研文档，进行测试时写测试文档和部署使用文档
1.2.3
根据业务量进行机器的数量和配置选择，最好将配置做成套餐，比如：将tomcat机器，每个都是8v16G硬盘100G，这个作为一个套餐来创建虚拟机或者云机器选购
1.2.4
根据需求进行主从或者负载均衡选择，可能还要选择备份容灾，cdn等等
1.2.5
对服务日志进行分析，比如ip来源地址，pv，uv
1.2.6
对服务和系统进行优化
1.2.7
安全防护不只有ddos，还有登陆问题。
多关注软件可能暴露的一些安全问题，或者linux本身的系统问题，说不定某个Nginx版本突然就有问题你还没关注到，那就很容易被黑掉
1.2.8
网络问题。
很多时候都是这样：只有某个地方访问慢，其他人访问不慢，这就很头疼，需要抓包再逐步排查
1.2.9
性能问题。
可能最初还好，但是随着压力来临，数据库可能有慢查询，需要进行排查和解决。网站可能有部分用户访问不了，或者访问缓慢，都需要去排查。这块需要各方面知识，如果遇到突然访问不了，那就回想之前做了哪些操作，再针对性排查
1.2.10
版本问题.
像Nginx1.9将支持tcp的4层代理，而不仅仅是之前的7层了，这样性能会提高很多，这对公司业务可能会很有帮助
1.2.11
优化不仅是系统的内核方面优化，还有服务的配置文件优化，这点需要长久深刻的理解才行。默认的都是最标准的，但是可以根据情况舍弃一部分来加强另一部分，来达到契合自己公司业务。比如Nginx做反向代理，可以优化内核参数，快速释放链接，超时时间配置短一些，这样可以处理更高的并发。但是如果提供php等服务的话，就要配置长一些，来达到稳定的效果
1.2.12
要考虑整体架构情况。
比如Nginx做负载均衡，可能抗压能力很出色，但是后面的数据库只有1台，导致数据库带宽被打满，也会造成访问不了的问题
1.3 发布来说
1.3.1
如何发布？是手动还是自动，考虑jenkins之类进行自动发布
1.3.2
容灾问题。
代码如果发布失败需要迅速回滚，不影响业务。发布的时候也不要所有节点一起发布，挨个节点发布
1.3.3
对老的代码进行备份，防止未来可能突然发生的问题，需要回滚
1.4 整体来说
1.4.1
运维并不是成天都是忙着去排错，大部分时间都是空闲的，这时候就需要自制力去学习新东西了
1.4.2
运维的价值 = 你节约的成本 x 你的意识 x 你的觉悟
运维并不能直接搞出价值，但是可以优化，调整结构来省钱，不出事就是最好的价值。同时分析日志能创造隐形的价值给公司。
1.4.3
优化现有的方式。
公司在成长中肯定会有很多隐患，比如最初是用一个脚本来批量操作10-20台机器，后面公司扩充有100台机器，就要用ansible来批量操作了。这些都需要自动化，后面还要自动发布，压力大了来自动扩容；报警cpu不够，自动调节缓解当前机器压力等等
1.4.4
服务不是照着百度把配置文件粘贴上即可。
像负载均衡，可能调度算法填写的不对，造成一台压力大，一台压力小。还可能服务占用一个cpu压力大，其他都闲着，这些都是不行的。要契合自己公司的业务和架构
1.4.5
文档要多写。
比如资产文档：机器的配置，还有密码表，服务连接文档，部署文档，维护文档等。文档的作用一个是自己用，另一个是等你离职或者新员工加入，他们可以快速来上手维护。
1.4.6
部署一个新服务，必须要测试过后再上线。测试不是安装即可，需要找数据来模拟线上环境。
1.4.7
操作谨慎甚微。
任何操作琢磨几遍再下手，不要很随意。比如重启线上Nignx用reload，否则当前业务中断了就会受影响。
1.4.8
监控很重要。
可以查看流量，某些服务使用内存是否超标，没有监控出了事都不知道，监控不仅要监控服务的端口防止挂掉，还要深度的使用，比如：mysql的慢查询，命中率，主从状态，域名证书的到期时间等等。
1.4.9
体系。
运维最好制定一些发布流程，虚拟机申请流程，巡检流程等等。巡检也是很重要的，云服务器也要定时看看是否磁盘满了，是否要续费等等。否则哪天出问题，问题就大了。
1.4.10
对业务进行机器规划，当压力大时扩容，利用率很小时考虑缩容
1.4.11
测试也重要。
一个服务从多方面进行测试，比如Nginx从静态页面，动态页面，提交数据，模拟多个在线用户登录访问来进行压测等等。
1.4.12
修改文件前必须备份，方便回滚，操作日志最好有审计
2、运维组织架构
2.1 简介
运维的工作方向比较多，随着业务规模的不断发展，越成熟的互联网公司，运维岗位会划分得越细。当前很多大型的互联网公司，在初创时期只有系统运维，随着业务规模、服务质量的要求，也逐渐进行了工作细分。一般情况下运维团队的工作分类和职责如下：
2.2 系统运维
系统运维负责IDC、网络、CDN和基础服务的建设（LVS、NTP、DNS）；负责资产管理，服务器选型、交付和维修。详细的工作职责如下：
2.2.1 IDC数据中心建设
收集业务需求，预估未来数据中心的发展规模，从骨干网的分布，数据中心建筑，以及Internet接入、网络攻击防御能力、扩容能力、空间预留、外接专线能力、现场服务支撑能力等多个方面评估选型数据中心。负责数据中心的建设、现场维护工作。
2.2.2 网络建设
设计及规划生产网络架构，这里面包括：数据中心网络架构、传输网架构、CDN网络架构等，以及网络调优等日常运维工作。
2.2.3 LVS负载均衡和SNAT建设
LVS是整个站点架构中的流量入口，根据网络规模和业务需求，构建负载均衡集群；完成网络与业务服务器的衔接，提供高性能、高可用的负载调度能力，以及统一的网络层防攻击能力；SNAT集中提供数据中心的公网访问服务，通过集群化部署，保证出网服务的高性能与高可用。
2.2.4 CDN规划和建设
CDN工作划分为第三方和自建两部分。建立第三方CDN的选型和调度控制；根据业务发展趋势，规划CDN新节点建设布局；完善CDN业务及监控，保障CDN系统稳定、高效运行；分析业务加速频道的文件特性和数量，制定最优的加速策略和资源匹配；负责用户劫持等CDN日常故障排查工作。
2.2.5 服务器选型、交付和维护
负责服务器的测试选型，包含服务器整机、部件的基础性测试和业务测试，降低整机功率，提升机架部署密度等。结合对公司业务的了解，推广新硬件、新方案减少业务的服务器投入规模。负责服务器硬件故障的诊断定位，服务器硬件监控、健康检查工具的开发和维护。
2.2.6 OS、内核选型和OS相关维护工作
负责整体平台的OS选型、定制和内核优化，以及Patch的更新和内部版本发布；建立基础的YUM包管理和分发中心，提供常用包版本库；跟进日常各类OS相关故障；针对不同的业务类型，提供定向的优化支持。
2.2.7 资产管理
记录和管理运维相关的基础物理信息，包括数据中心、网络、机柜、服务器、ACL、IP等各种资源信息，制定有效的流程，确保信息的准确性；开放API接口，为自动化运维提供数据支持。
2.2.8 基础服务建设
业务对DNS、NTP、SYSLOG等基础服务的依赖非常高，需要设计高可用架构避免单点，提供稳定的基础服务。
2.3 应用运维
应用运维负责线上服务的变更、服务状态监控、服务容灾和数据备份等工作，对服务进行例行排查、故障应急处理等工作。详细的工作职责如下所述：
2.3.1 设计评审
在产品研发阶段，参与产品设计评审，从运维的角度提出评审意见，使服务满足运维准入的高可用要求。
2.3.2 服务管理
负责制定线上业务升级变更及回滚方案，并进行变更实施。掌握所负责的服务及服务间关联关系、服务依赖的各种资源。能够发现服务上的缺陷，及时通报并推进解决。制定服务稳定性指标及准入标准，同时不断完善和优化程序和系统的功能、效率，提高运行质量。完善监控内容，提高报警准确度。在线上服务出现故障时，第一时间响应，对已知线上故障能按流程进行通报并按预案执行，未知故障组织相关人员联合排障。
2.3.3 资源管理
对各服务的服务器资产进行管理，梳理服务器资源状况、数据中心分布情况、网络专线及带宽情况，能够合理使用服务器资源，根据不同服务的需求，分配不同配置的服务器，确保服务器资源的充分利用。
2.3.4 例行检查
制定服务例行排查点，并不断完善。根据制定的服务排查点，对服务进行定期检查。对排查过程中发现的问题，及时进行追查，排除可能存在的隐患。
2.3.5 预案管理
确定服务所需的各项监控、系统指标的阈值或临界点，以及出现该情况后的处理预案。建立和更新服务预案文档，并根据日常故障情况不断补充完善，提高预案完备性。能够制定和评审各类预案，周期性进行预案演练，确保预案的可执行性。
2.3.6 数据备份
制定数据备份策略，按规范进行数据备份工作。保证数据备份的可用性和完整性，定期开展数据恢复性测试。
2.4 数据库运维
数据库运维负责数据存储方案设计、数据库表设计、索引设计和SQL优化，对数据库进行变更、监控、备份、高可用设计等工作。详细的工作职责如下所述；
2.4.1 设计评审
在产品研发初始阶段，参与设计方案评审，从DBA的角度提出数据存储方案、库表设计方案、SQL开发标准、索引设计方案等，使服务满足数据库使用的高可用、高性能要求。
2.4.2 容量规划
掌握所负责服务的数据库的容量上限，清楚地了解当前瓶颈点，当服务还未到达容量上限时，及时进行优化、分拆或者扩容。
2.4.3 数据备份与灾备
制定数据备份与灾备策略，定期完成数据恢复性测试，保证数据备份的可用性和完整性。
2.4.4 数据库监控
完善数据库存活和性能监控，及时了解数据库运行状态及故障。
2.4.5 数据库安全
建设数据库账号体系，严格控制账号权限与开放范围，降低误操作和数据泄露的风险；加强离线备份数据的管理，降低数据泄露的风险。
2.4.6 数据库高可用和性能优化
对数据库单点风险和故障设计相应的切换方案，降低故障对数据库服务的影响；不断对数据库整体性能进行优化，包括新存储方案引进、硬件优化、文件系统优化、数据库优化、SQL优化等，在保障成本不增加或者少量增加的情况下，数据库可以支撑更多的业务请求。
2.4.7 自动化系统建设
设计开发数据库自动化运维系统，包括数据库部署、自动扩容、分库分表、权限管理、备份恢复、SQL审核和上线、故障切换等功能。
2.5 运维研发
运维研发负责通用的运维平台设计和研发工作，如：资产管理、监控系统、运维平台、数据权限管理系统等。提供各种API供运维或研发人员使用，封装更高层的自动化运维系统。详细的工作职责如下所述。
2.5.1 运维平台
记录和管理服务及其关联关系，协助运维人员自动化、流程化地完成日常运维操作，包括机器管理、重启、改名、初始化、域名管理、流量切换和故障预案实施等。
2.5.2 监控系统
负责监控系统的设计、开发工作，完成公司服务器和各种网络设备的资源指标、线上业务运行指标的收集、告警、存储、分析、展示和数据挖掘等工作，持续提高告警的及时性、准确性和智能性，促进公司服务器资源的合理化调配。
2.5.3 自动化部署系统
参与部署自动化系统的开发，负责自动化部署系统所需要的基础数据和信息，负责权限管理、API开发、Web端开发。结合云计算，研发和提供PaaS相关高可用平台，进一步提高服务的部署速度和用户体验，提升资源利用率。
2.6 运维安全
运维安全负责网络、系统和业务等方面的安全加固工作，进行常规的安全扫描、渗透测试，进行安全工具和系统研发以及安全事件应急处理。详细的工作职责如下所述。
2.6.1 安全制度建立
根据公司内部的具体流程，制定切实可行，且行之有效的安全制度。
2.6.2 安全培训
定期向员工提供具有针对性的安全培训和考核，在全公司内建立安全负责人制度。
2.6.3 风险评估
通过黑白盒测试和检查机制，定期产生对物理网络、服务器、业务应用、用户数据等方面的总体风险评估结果。
2.6.4 安全建设
根据风险评估结果，加固最薄弱的环节，包括设计安全防线、部署安全设备、及时更新补丁、防御病毒、源代码自动扫描和业务产品安全咨询等。为了降低可能泄露数据的价值，通过加密、匿名化、混淆数据，乃至定期删除等技术手段和流程来达到目的。
2.6.5 安全合规
为了满足例如支付牌照等合规性要求，安全团队承担着安全合规的对外接口人工作。
2.6.6 应急响应
建立安全报警系统，通过安全中心收集第三方发现的安全问题，组织各部门对已经发现的安全问题进行修复、影响面评估、事后安全原因追查。
