回复 10# action08
这不就是摸着石头过河么..理论比实践来得容易。我现在的公司也想搞devops，但是进度也不是很快，很多时候概念都不清晰的话也很难推动
习惯传统开发方式的人，毕竟习惯是很难改过来的。
de vo p s 算是运维中得妈弄。想做好真的有运维经验，搞个2，3年出来做这个感觉还是欠缺。运维基础及运维经验对于devops来说非常重要，如果你想成为一名真正的devops话
沟通无极限，共识促发展。
本帖最后由 cryboy2001 于 2014-06-13 08:57 编辑
action08 发表于 2014-06-12 15:38 static/image/common/back.gif
我先谈一下自己的观点，公司开发不是都有文档么？？？
不是做任何事情，有标准就能做好的，标准只是指导这么做，而且定标准也不是那么容易的，范围定的大，做事灵活，有利于发挥个人才能，范围定的太细，真正做事时，会发觉按标准做会很坑跌的。
开发都是发个人的才华，这与工厂流水线不一样，工厂流水线定标准是越细越好，因为只要动手，不要动脑。
如果有这么简单，那开发就不会与运维出现分歧了，也不会与客户有大分歧了，大家都按标准做的话。
本帖最后由 action08 于 2014-06-13 09:01 编辑
回复 15# cryboy2001
有些环节把标准做好了非常重要，标准是部门与部门沟通的重要渠道，就跟大路上的信号灯一样
至于工程师发挥才华铺路，管你用沙子铺路，砖头铺路，石头铺路，还是钢铁铺路，你的自由，别人不管
开发与运维，文档基本就可以了。
你说的情况，还是公司在开发环节投入不够，包括文档建设
seesea2517 发表于 2014-06-12 15:11 static/image/common/back.gif
咱这原来大家随意找开发问问题，打乱人家的开发步骤确实不好意思，而且有时候不确定软件问题是哪个开发的， ...
有研究表明，当正在工作时被打断，可能要10-15分钟才能重新回到原来的工作上，如是思考问题被打断，要回复的时间可能更长，甚至有的思路已不会再出现。
回复 18# cryboy2001
是啊，所以这也是造成被打断者心情不悦的一大原因，也因此对打断流程做了调整。
开发方面一般会有专门的接口人负责协调与其他部门的关系吧 有事情直接找接口人联系相关事宜