oncall的问题
1，问题处理，
包括客户提出的问题，运营提出的问题，他们是系统的使用者，会有各种各样的问题出现，
2，告警处理，
接入各类告警系统，这些都是通过日志分析统计出来的，所以要做日志整改，会发送邮件和短信，及时告警，告警要时刻处理，
包括流量的监控，功能拨测用例的执行，日志分析所有的请求有没有异常状态码，如果有就会告警，就要分析，
3，例行巡检，先于客户发现问题
3.1 要保证各类告警系统是正常的，告警系统不正常了，就不会有自动的告警了，这很危险，
3.2 服务器各项指标的监控，常态：cpu占用<15%，内存占用<30%，磁盘空间<50%等，
上面两步要保证各类告警系统和服务器的各项指标的趋势是稳定的，如果有激增，有阶梯式的，有量级的变化就要有所分析了，否则就会有潜在的风险
3.3 例行巡检关键功能，比如首页打开，主流程的畅通，接口正常，
4，容灾环境，
必须要有容灾环境，这样出现问题你就会有一个缓冲，即使这个容灾就是只读的也可以，为我们解决问题提供时间，不至于赤裸裸的暴露在客户面前，半死也比死掉好，
你有容灾环境，你解决严重的现网问题的时候就不会手抖，遇到崩溃级别的现网问题，手都会抖，脑子一片空白，根本不知道干什么，别人说做什么就做什么了
所以平时一定要有容灾的演练！！只有这样才能应急，
5，回溯报告，
出现大的现网问题，都必须要有回溯报告，找到问题的根因，按照问题回溯------定位问题--------改进措施的思路，是什么，为什么，怎么办？有整套方案
==========================
如果对系统进行性能测试？
1，首先就是要知道系统的常态数据，每一个接口每天的访问量，常态是10，峰值就要支持100，扩容之后就要支持1000，
这个就要使用到流量的监控工具，每一个接口的常态数据，就要做日志整改，
2，有了基线常态数据，就要根据，常态数据，做压测目标，就是峰值是常态的10倍，扩容之后是常态的100倍，
要根据接口测试，也可以统计到每一个页面的接口，根据页面测试
也可以梳理出来关键场景，每次上线做例行10倍流量测试的看护场景，
所以可以分为，接口级别的，页面级别的，场景级别的，
3，横向扩容问题，服务器从两天，扩容到8台，
快速的扩容，需要有一个前提条件就是服务器是无状态的，也就是数据库缓存都是共享的，这样访问每一个节点返回的数据都是实时的
做流水线的运营部署，容器化的部署，这样只需要改一些配置就能做到10分钟之内迅速的扩容，而不是传统的还需要每一台服务器部署代码，做配置，
但是所有的这些例行的都有一个前提，就是你的代码逻辑是没有问题的，
1，确保你的代码没有低性能的命令，比如redis 的keys命令，和hgetall命令，
2，确保你的代码没有那种无限循环的任务，自己把自己搞死，
比如所有的外部服务都应该是可以抛弃的，就是所谓的应急放通机制，
比如，redis的连接超时问题，连接超时就要断开，去查数据库，不能卡死在查redis这里，redis不能保证自己一定是活着的，
比如，redis查询超时了，比如多少秒查不到，就要断开连接，查数据库这样的机制，不能排除redis服务会死掉了，或者假死了，不能影响业务主流程，
扩展一下，所有不必要的外部服务都应该有应急放通的机制，都应该在不通的情况下不影响主流程的能力，
不考虑超时场景的程序员都是初级程序员，不考虑历史数据兼容的问题也是初级程序员，
必须要保证自己的代码逻辑没有问题，否则你做再多的扩容也没有用，
系统不能保证一个1000个人的活动，这系统就是有问题的，
==================================
做的所有的这些，就是为了保证在极端情况下，保证业务是正常的，否则你做再多的需求，再多的功能，业务中断了，都没有用，
=======
性能测试目标：
在版本平稳交付的同时，通过接口场景级性能优化，升降配，流控，容量预测等技术手段做好后台性能的持续接口看护，无因性能问题漏测导致重大的网上事故，实现现网零事故，客户零投诉的目标，