配置不当那些事，你怎么看？

niao5929

有时候配置错了带来的结果会非常严重。记得当年就把SYSBASE的系统表修改了。导致数据库下线。后来做DD倒成文件修改。那是想当的麻烦，还好那个年代的数据库停机也不是很要命。那个时候系统停摆3天也没什么大问题。现在很多系统已经进化成了生产环境基础，停上30分钟那不知道要损失多少银子呀。所以先在一定要胆大心细，敲回车的手一定要慢一点

ChinaUnix第一帅

回复 21# niao5929


    吓坏了

1. 这种事情我干过，而且是因为一只鸡。不要多想，真的是鸡，一只鸡的鸡，不是一个鸡的鸡……
   
2. 
   
3. 
   
4. 背景交代：
   
5. 事故发生在两年前，那时候我所在的公司主要客户是某国家暴力机关，我当时负责某省的售后技术，所负责的系统用户数跟互联网公司比起来不算什么，但也是以万为单位的量级，而且都是该机关的国家公职人员。
   
6. 
   
7. 事情经过是这样的：
   
8. 某天上午快下班的时候接到一个客户电话，说他把密码忘记了，让我们给重置一下。因为是内部专网系统，也因为接近中午脑子里想的都是吃，所以我甚至没有核实对方身份就进了数据库改密码。
   
9. 
   
10. 已经说过，当时肚子太饿，只想着改完赶紧去吃饭。事实证明，在原始生理需求面前，真的会让人丧失理智。
    
11. 
    
12. 平时为了防止出错，我一般都会用DB来修改数据库，但是当时我正好远程登录了机房的服务器，本地机器也没有开DB，所以我就直接用SQL语句给客户改密码。结果，就是为了这个方便，外加脑子里在思考一会吃什么这个永恒的人生难题，我犯了一个超级低级的错误：我只写了update 表名 set passwd=123456就开始执行！对，我没有写where useid=******。也就是说我把上万个用户的密码都改成了123456！！！
    
13. 
    
14. 当屏幕上显示上万条数据更新完成的时候，我脑子里面想的是一会吃凉鸡还是吃牛肉，要白菜还是茼蒿……一秒钟之后，我终于清楚的意识到发生了什么事情！去你妈的凉鸡！去你妈的茼蒿！我现在想吃刀！
    
15. 
    
16. 不幸中的万幸是事发时离下班只有十几分钟，更幸运的是国家机关工作人员的下班都极其准时甚至只会提前。事实也证明当时真的恐怕已经没有几个人还在岗位上，因为所有人的办公系统都被踢出来了我却没有接到一个电话……
    
17. 
    
18. 事情既然已经这样发生，我就不能只是悲伤的坐在你身旁，想办法解决吧。
    
19. 其实也不用想，因为留给我的只有还原数据库这一个选择。但这也只是一个无奈之举而不是一个天衣无缝的方案，因为我们的数据库备份计划任务是一天一次。也就是说我只能把这张表还原到昨天的状态，但是谁也无法知道这一天之内几万用户有多少人自己改过新密码，而且这种单位人事变动又很频繁，我只能很不爱国的期待这些国家公职人员很懒或者安全意识很低从来不修改密码了……
    
20. 
    
21. 事情最后的结果是：
    
22. 1、还原数据库后的整个下午我接了十几个电话反应他们早上新修改的密码登录不了，我只能告诉他们，不如你用旧密码试一下啦，说不定会有惊喜哦……这说明这个国家其实还是很有希望的，还是有很多国家机关工作人员兢兢业业努力工作不怕麻烦安全意识很高的；
    
23. 2、公司并没有知道这个事故，因为客户的所有问题都是先反映到我这里再由我反映到公司，我喜欢吃的东西很多，但是不喜欢吃鱿鱼，所以没有理由我给自己买鱿鱼吃；
    
24. 3、当天中午我没有吃到午饭……
    
25. 
    
26. 这件事情告诉我们一个道理：做任何事情，包括搞机、搞鸡、搞鸡和搞基，都一定要专心，千万不能在搞机的时候想着搞鸡、搞鸡和搞基，不然最后你可能什么ji都搞不到！

复制代码

可以看看这个。 如果误删之类的操作。 其实我觉得挺好笑的。

1. 当屏幕上显示上万条数据更新完成的时候，我脑子里面想的是一会吃凉鸡还是吃牛肉，要白菜还是茼蒿……一秒钟之后，我终于清楚的意识到发生了什么事情！去你妈的凉鸡！去你妈的茼蒿！我现在想吃刀！

复制代码

chenyx

系统管理权限的分配一直是系统安全的重点,很多Iter的血泪史都是在Root权限的情况下执行rm -fr /的例子.所以,如果有条件,还是现在测试条件下调试,成功之后再在线上部署.

ylky_2000

1.某些服务配置的过程中，你或者不知道，或者是猪队友配置的，导致了整个公司数据被脱了，这种现象该如何防和如何进行人员培训？
    1.1看规模，规模小团队小的（2个人），知会一声，就可以避免；
    1.2大于2个人的团队，建议配置规范化，大家按照规范手册来配置记录配置过程（类似版本控制），并且配置应用之前要（交给第二人）审核，通过才可以下发配置。简单的说 配置流程 规范化、标准化。形成了标准和规范，直接培训后来者，大家都按照这个规范和流程来进行。
    1.3 人员提升方面  部门或者组内 组建知识库，将日常处理的问题积累起来，形成知识库。
   1.4 前面是内部培训，毕竟不是很系统，可以引入一些比较系统的外部培训，优点  快，缺点 花点钱和占用几天时间。

2.像某些服务刚出来，手册资料都还不全，但很可能某个配置会产生安全问题，作为一名运维或管理人员该如何在接触新服务的时候，要注意那些问题？
   个人经验：
    2.1服务器配置安全方面：先基本安全配置过一篇；然后针对新的配置项，从软硬两个方面考虑总结安全方面的配置，进行测试，并将最终的测试结果形成标准放入配置规范标准中。
     2.2考虑是新服务器，应该在服务范围之内，建议初次上线过程，请厂家派有经验的工程师指导。
     2.3 新服务器落地前要进行验货，包括关键配件是否是二手货等；
     2.4新服务器测试 入硬盘的吞吐、cpu、内存、服务器的稳定性等。。。。
     2.5 当系统搭建好后，除自己测试外还可以借鉴第三方安全工具测试 入百度安全、360安全 阿里安全等，他们可以检查出一些常见的安全隐患。
3.运维或安全人员会经常编写一些脚本来测试吗？写过哪些类型的测试代码？
     3.1这个没有深入接触，一般都是使用第三方工具，如nessus进行测试。
     3.2简单的，会写一些压力测试脚本 使用ab工具进行 web服务器的压力测试。

jieforest

1.某些服务配置的过程中，你或者不知道，或者是猪队友配置的，导致了整个公司数据被脱了，这种现象该如何防和如何进行人员培训？
运维部署需要建立一套行之有效的制度，把通常容易犯的错误通通避免。
比如服务器资源（无论是物理机还是虚拟机），默认情况是通过镜像安装的，安装后防火墙一定是开启了的，默认除了SSH端口外，所有端口均为关闭状态。再根据业务部署的需求，开通相应的端口。
还有很多安全措施细则，所有的新进运维团队的员工都必须学习，遵守公司的运维制度。
还要建立一套安全审计制度。

2.像某些服务刚出来，手册资料都还不全，但很可能某个配置会产生安全问题，作为一名运维或管理人员该如何在接触新服务的时候，要注意那些问题？
如果公司的服务器规模较大，通常会在安全领域投入资金，那么对于接触的新服务，部署后就可以用开源或商业的漏洞扫描工具，对整个服务器做漏洞扫描，查看是否存在安全问题。

3.运维或安全人员会经常编写一些脚本来测试吗？写过哪些类型的测试代码？
会编写脚本进行测试，这是很常见的现象。
尤其是做集群之类的运维时，有时候为了探测节点是否宕机，会编写一个脚本定时检测。
有时为了保证服务的持续有效，也会编写脚本来查看服务是否正常运行。
又比如对服务器网络的检测，对多线机房的服务器，编写脚本，通过多个监测点发起脚本访问，看每条线路是否畅通等等。
这些都是Shell脚本的基本功，有时也使用Python写脚本。