OPENSTACK运维感想

一个PRO环境中的Openstack集群，在倒下后1个月还没完全恢复，我也是醉了。如果不在这里，实在无法想象到外企的工作效率。

不过还好坑的只是部门内部的人，倒也没闹出什么大的幺蛾子。

一个月下来，有些感想，仅作记录吧。

1.永远不要低估一个线上操作的影响。

   线上的每个操作，都应该在beta环境经过测试验证没有危害才能实行。有些操作可能看起来只会影响那么一点，但是总会有那些隐藏的side affect.

2.一个和PRO环境一致的beta环境。

   beta环境的重要性是毋庸置疑的，用beta环境首先得明确beta的作用，它存在的意义应该是为PRO环境变化做实验。像我们不停的拆东墙补西墙，把beta环境拆的乱七八糟的来缓解 PRO环境的危机是不可取的，这样做只会让PRO环境越来越乱，beta环境越来越凋零。

   所以一个好的beta环境应该是：

       a.架构和PRO基本一致，且不说一致到机器型号，整个集群的架构应该是一致的，比如多台CN，一台CC

       b.OS，软件版本必须一致

3.操作权限管理

    对集群的操作权限管理是个很蛋疼的问题，既要不影响平时的开发运维，又要防止不可靠之人（比如我）的瞎眼操作。

    对于配置的更改： puppet   自动化部署已经不是新鲜事了，但是总会有人偷懒自己去改配置而不是通过Puppet，所以总会有一些诡异的事发生。

    对于需要admin权限的操作：我觉得对horizon的权限应该开放给基本可靠之人，运维工作人员也算是半个admin，如果和普通用户一样的权限，那活就没法干了，当然也可以不怕麻烦的设置个半admin状态的用户，可以自己去慢慢grant一些权限。

4.凝聚力

    一个混日子的团队是不会有高的工作效率，作为一个scrum的团队，既然人不多，就应该要关注到每个人的情绪和状态。木桶效应随时会在teamwork中发生，一个积极性不高的人，可能会影响整个团队工作的进度，卡壳会经常发生，这样的话，频繁的迭代还怎么实现。

    可能不是每个人都对别人的感觉很敏锐，so，这一点，只能看scrum master是否优秀了吧。

PS： 虽然集群恢复的很慢，但是这一个月来我的收获还是蛮大的。作为一个才来的时候linux一窍不通、搭个3节点都要一个月的人，前几个月都是干一些边角活，起码现在我能接触到组里最核心的东西了。

可是这一个月的代价未免也太大了。