做运维需要考虑的事 简介 /* 运维是在于一个量 最少的人，最多的事 并且保证业务 比如说google的一个数据中心，只有几个人在维护 运维不能直接的创造价值，而是可以变相的节约成本 你节约的成本x你的意识x你的觉悟=你的价值 ———-来自 98素辞 */ 服务来说
1.对服务版本选择，要和开发沟通，如果开发用的php语言，那就问他写的代码是哪个版本的，不同版本可能不兼容一些语法，会导致出错
要选择稳定版，太新的可能会导致一些bug，从而崩溃或服务出错。选择新版本唯一的目的应该是需要新的功能，否则老的版本最稳定
服务部署后要进行简单测试，让服务可以照常运行才可以，不能装完就算了。对于java这种替换版本，1.7升级到1.8可能导致某些依赖1.7的JDK，这都要去考虑清楚。
当服务运行后要注意他的启动用户是什么，可能用户不对造成无法读取文件。比如nginx启动时www用户，他就没法读取/data里找html发送给用户。
数据库如果要和库，要考虑是否有表名字重复。如果公用一个redis进行缓存，要考虑写入的数据是否冲突。
2.根据业务进行结构分析，是使用nginx还是apache，选择前填写调研文档，进行测试，写测试文档和部署，使用文档
3.根据业务量进行机器的数量选择还有配置选择，最好将配置做成套餐，比如将tomcat机器，每个都是8核16G内存，硬盘100基础，这个作为一个套餐来创建虚拟机或者云机器选购。
4.根据需求进行主从，或者负载均衡选择，可能还要选择备份容灾，cdn等等
5.对服务的日志进行分析，比如ip来源地址，pv，uv
6.对服务和系统进行优化，优化前和优化后差别很大，性能可以差一倍。
7.安全防护，不只有ddos，还有登陆问题。多关注软件可能暴露的一些安全问题，或者linux本身的系统问题
说不定谋个nginx版本突然说有问题，你还没关注到，那就很容易被黑掉
8.网络问题，很多时候都是这样，某个地方访问慢，但其他人访问不慢，很头疼，需要抓包再逐步排查
9.性能问题，可能最初还好。随着压力来临，数据库可能有慢查询，需要进行排查和解决。网站可能有部分用户访问不了，或者访问缓慢，都需要去排查
这块是最难得，需要各方面知识，如果遇到突然访问不了，那就回想之前做了哪些操作，再针对性排查
10.关注版本问题，像nginx1.9将支持tcp的4层代理，而不仅仅是之前的7层了，这样性能会提高很多，对公司业务很有帮助
11.优化，不仅是系统的内核方面优化，还有服务的配置文件优化，这点需要长久深刻的理解才行。默认的都是最标准的，但是可以根据情况舍弃一部分的东西，来加强另一部分，达到适合业务。
比如nginx做反向代理，可以优化内核参数，快速释放链接，超时时间配置短一些，这样可以处理更高的并发。但是如果提供php等服务的话，就要配置长一些，来达到稳定的效果
12.要考虑整体结构情况。比如nginx做负载均衡，可能抗压能力很出色，但是后面的数据库只有3台，导致数据库带宽被打满，也会造成访问不了的问题
发布来说1.如何发布，是手动还是自动，如果机器多了，需要jenkins之类进行自动发布
2.容灾问题，代码如果发布失败，需要迅速回滚，不影响问题，发布的时候也不要所有节点一起发布，挨个节点发布
3.还要对老的代码进行备份，防止未来可能突然发生的问题，需要回滚
整体来说1.运维并不是成天都是忙着去排错，大部分时间都是空闲的，这时候就需要自制力去学习东西了
2.运维的价值=你节约的成本 x 你的意识 x 你的觉悟
运维并不能直接搞出价值，但是可以优化，调整结构来省钱，不出事就是最好的价值。同时分析日志能创造隐形的价值给公司。
3.优化现有的方式，公司在成长中，肯定会有很多隐患，比如最初是用一个脚本来批量操作10-20台机器，后面公司扩充有100台机器，就要用ansible来批量操作了。这些都需要自动化，后面还要自动发布，压力大来自动扩容，报警cpu不够自动调节缓解当前机器压力等待
4.服务也不是照着百度吧配置文件放上即可，像负载均衡，可能调度算法填写的不对，造成一台压力大，一台压力小。还可能服务占用一个cpu压力大，其他都闲着，这些都是不行的。
5.文档要多写，比如资产文档，那些机器的配置，还有密码表，服务连接文档，部署文档，维护文档都要写，文档的作用一个是自己用，另一个是等你离职或者新员工加入，他们可以快速来维护。
6.部署一个新服务，必须要测试过后才上线，而测试不是安装即可，需要找数据进行深度测试，模拟线上环境。
7.谨慎甚微，任何操作琢磨几遍再打，不要随意就打了，比如重启线上nignx用reload，否则当前业务中断了。