序言
核心系统已经平稳运行一周，人肉运维的时代，的确还是比较痛苦的。

运维，很多时候看起来是琐事，但是其中的乐趣只有你自己去做了之后才能体会到，那么，这到底是一种trouble还是一种happy的事情呢？

风言风语
1 产品即服务

现在，很多的技术在消失，很多的新技术也在不断的涌现，但是很多如昙花一现，你能看准哪个技术能活多久么？

容器的霸主，docker推出了swarm，最后被k8s打成了一坨屎，成也萧何，败也萧何。

云服务在不断的推出，运维的工作会越来越少，自动化的东西或者专业化的东西都会被底层的IAAS和PAAS所取代，那么运维在未来会走向何方？

无论是业务团队，还是技术团队，代表了什么使命，宣扬出了什么样的产品理念？所谓的价值即产品，理念即产品，也就是完全为了推出产品。

产品，在很多时候只是一个api的调用，并未有任何创新就战无不胜，例如k8s，没有重复造一个轮子，而是直接借docker上位，相互配合相互促进的关系，但是为什么swarm直接被干掉，也就是所谓的原生的编排技术，亲生的被野生的干掉。。。

服务是什么？所谓的服务，服务一定是围绕产品展开的，技能也是围绕产品展开的，业务也就是产品，那么产品就代表了这么多的东西，一项理念，如果需要靠嘴说，那么就很难了；一项制度流程，如果也需要靠嘴说，那么更加难了。。。嘴巴不可靠，大风容易闪了舌头。

很多时候，不同的角度来划分，从而划分为业务团队，也划分为基础团队，做业务的心心念着做基础组件，而做基础的天天想着业务运行情况，拥有的不知道珍惜，啊呸。。。

不同的时期，享受着不同的过程，结果可能很重要，但是过程才是更加重要的。

2 产品

天天说产品，卖什么？到底是卖肉还是卖灵魂？灵魂就在产品中。。。

昨日之代码，今日之基础，明日之未来。。。昨天的代码就是积累，昨天运维的经验也是一种积累，而积累是盘旋上升的，而不是断层一样抛弃的。。。

抛弃的太多，遗忘的太多，那么明日复明日，明日何其多。。。

再好的机制，都要人去做；再好的人，也需要舞台去表演。很多时候，业务太大，从而存在人员不足，技能不足等各种问题，而有的时候也存在业务稳定，系统稳定，而无太多的创新突破，从而被质疑工作饱和度不足。

无论是太忙还是太闲，这是一种悖论，如何减少冲突，软件的不断变化从而导致业务不断变化，技术不断变化，团队不断变化，必然的结果，无法消除，只能去适应这种变化。

我们总是期望教会别人，但是你最终会发现，一等人不用教，二等人用言教，三等人用棍棒，但是也会发现。。用棍棒教会的最终都是无效的。。。只能依赖他们自己的思考。。。

所以，很多时候，你只能改善自身，而不要去批评，不要去指责别人，毕竟，在不同的场景和位置的思考下，你不知道别人的顾虑是什么。

坚持，是坚持改变自身，是不断的提升自己，当你想把自己的观点强加于别人的时候，你遇到的只有反抗和无穷的阻力，那么要说服别人，你只能依赖全局的解决方案，说清楚，why？how？what。。然后才有机会。。。

教会了别人有价值的事情，最终你自己得到的只有负面情绪。。。

3 备用方案
当我们做事的时候，如果依赖于人，实际上完全无法自动脱离人，会碰到各种各样的人。

主攻杀伐，那么将是一种强大的冲击，只有对手才能迎接，但是对于合作的来说，就远远的不能接受了，从感情上来说，伤害了别人的感情。。。不好意思，我是一个没有感情的杀手。

你最方便的方式，不一定是别人期望的，也不一定是别人看起来最优的，所以呢。。。要有备选方案，例如三分钟换一杯奶茶。

既然是一个没有感情的杀手。。。为啥还带有情绪呢？这个问题值得思考。。。

抱怨不会解决问题，而是加剧问题。。。其实很多问题是从你出发的角度，有的适合你看到的是抱怨，而别人看到的是本质问题，看问题的角度不同，就产生了不同的寓意，这就是语言的最大魅力。

强调一个问题，是为了解决问题，是因为提前预到了未来可能遇到的问题，所以要感恩指出你问题的人，要不然别人会认为。。。你犯错，关我屁事，不要让自己陷入困境，知错就改，不就打脸么，不怂。。。

面对疾风吧。。。你哭我就笑，你闹我就跳，你叫我就哈哈笑。。。运维不知好歹的娃儿已经一周了。。。核心系统，一级系统，baby的运维应该是最有压力的，毕竟故障恢复时间不多。