关于运维，闲聊几句

不知不觉做运维快六年了，在这家公司呆了四年，做过监控，参与过内部系统的开发，也做过一线的运维，当然也出过故障，目前仍是�潘恳幻丁Ｃ康侥甑祝�就是我们最忙的时候，比如最近。 我们的站点是一个很 复杂的系统，整块大业务的运维团队有百来号运维工程师。废话不多说，至少我认为还存在以下几个问题。

1、运维自动化。 我们的运维自动化，在国内并不算领先。虽然有了自己的CMDB、资产管理、上下线&扩容平台、配置发布系统，但运维依然可以做得更好。我们甚至没有配置管理系统，大部分生产变更依然是靠工程师在人肉，比如，我们甚至连一个应用日志的管理都还是靠人肉在控制。虽然工具可能导致工程师丢掉饭碗，但这是历史的进步。未来的趋势是，统一所有的运维团队，我指的是运维工具、规范、平台、以及IDC运营的一体化。当然，这是我们大老板才关心的事，我们小人物想象一下就行了。

2、严格按业务进行运维分工，这个是现实情况导致的，我们的业务线、产品线多达数百上千，一个运维工程师甚至可能负责上百个应用的日常运维，有些人负责核心的重要应用比如交易，有些人则负责一些二三线应用，比如一些后台等等。我认为我们未来的趋势是渐渐消除这种分工，因为我们未来的运维架构会变化。原来我们放在某市的主站机房的交易系统，未来分成一个个的变易单元，分布在多个机房，每个机房承担一定的业务流量。简而言之就是异地容灾，打个比方，5个机房，每个机房承担20%的交易订单。当然，这样的系统非常复杂，还涉及后端缓存、数据库的异地化，但我们不可避免地要走上这条路，可扩展，高可用性是我们的目标。除了交易以外的其他业务，我们认为它们不需要分单元，比如我们的广告结算业务、分佣系统、CRM系统。N年后，我们只需要一些架构师，每个架构师负责运维一部分交易单元，或者非交易业务。当然，实现这些的前提是，我们的运维自动化程度已经非常高了。