如何说服运维选择 Debian/Ubuntu 而不是 CentOS？

作为一个苦逼运维，我们作为服务部门，如果开发大爷们真对os有特定要求，那是一定要满足的；

但是前提是你的要求是合理的~

题主说的几点，我随便代表你们运维回你几句：

1.更新及时：生产环境首要是稳定，你要用最新版可以，说个用最新版的理由先，没有这个特性你代码就写不下去了？或者有了这个巨NB的新特性，我可以少造1000个轮子，开发效率提升100%？

2. 资料丰富。都是linux，资料基本共通的，这个理由是个什么鬼？

3. 社区支持。同2

----------------------------------------------------

为什么我要匿名呢，因为我要开始不友善的攻击楼主了

lz你待的是小公司吧，你们公司生产环境和测试环境不分的么？测试环境你爱用Ubuntu就ubuntu，爱怎么折腾怎么折腾，运维都懒得管你；

至于生产环境，你管得着么你？你是开发，你只要提需求，运维评审后，理由充分，有什么不给装的？至于生产环境用啥os，和你一个开发有个毛线关系？生产环境不是为了满足你追求新技术的地方！

-----------------------------------------------------

老实说，题主你描述的越多，显的你水平越low啊，因为你们公司的运维水平太low啊，一家公司的运维水平和开发水平明显正相关啊；

运维的价值体现在装软件？“Ubuntu太简单了，如果大家都用Ubuntu，运维的价值无法凸显，运维就是要把系统弄的不那么方便才“安全””这句话我简直无力吐槽

------------------------------------------------------

明显

的答案比我说的更好更细致；

-------------------------------------------------------

补充几点：

1.选os和选ide差不多，弄到最后就上信仰了要，完全没必要；

我作为一个运维，用过centos,suse,debian,slackware;

同代次的发行版的差异明显没有造成工作量上的巨大差异，倒是发行版的大版本升级，反而会带来业务改造的工作量

2.开发和运维明显是合作关系，大家平时相互体谅下，都是为了工作；另外在某些开发鄙视运维什么都不懂的时候，运维也许也在私下里传“那个XXX，平时叼的很，指手画脚，结果代码上线，三天两头core，天天到我这里gdb;没上线前要我们装这装那，结果测试和我说tps简直感人”

尊重他人也是尊重自己

3.作为运维，装软件真的只是日常工作中很小的一部分；难道作为开发，装软件占据了你大量的工作量？大家都有太多的事，何必在这种普通运维和开发都没有决策权的事上，非要挣个一二三？

而我认为应该用Ubuntu的原因主要是：
1. 更新及时。有些基础工具CentOS要比Ubuntu落后好几个版本，对于喜欢尝试新技术的开发者来说，逐个手动安装依赖是个很痛苦的事。
2. 资料丰富。遇到什么问题，在网络上比较容易找到答案。
3. 社区支持。因为Ubuntu社区庞大，有些工具虽然没有在apt源收录，但是基本都会提供Ubuntu下的安装过程。
综上，我认为使用Ubuntu的运维成本更低。

第一点只是说明了对开发者的好处, 并不能得出"使用ubuntu的运维成本更低"的结论.

第二点, 先不提究竟哪个发行版资料丰富, 这两个不是都是linux么, 具体的linux相关的资料都是一样的啊, 当然如果先用了ubuntu, 并且也按照ubuntu特定的东西去找的花, 肯定是这个的资料多了啊, 另, 试试找英文资料....., 最后, centos对运维来说已经有很完善的资料了, 所以这一点得不出"使用ubuntu的运维成本更低"

第三点, 有哪个特定常用的东西没有fedora/centos的支持么? 非要举出特例的话自然另当别论了, 不过笼统的讲, 也得不出"使用ubuntu的运维成本更低"的结论吧

事实上, 楼主忽略了最重要的问题了感觉, 对于一个生产系统来讲, 最主要追求的并不是"成本", 而是"稳定"

尤其是楼主提出的第一个原因, 恰恰是稳定的大忌的

这也是为什么Redhat要在RHEL之外, 另外资助搞一个Fedora的原因, 就是为了让一些新的技术/软件, 先进入到Fedora的社区中, 等这些新的软件经过了社区的检验, 迭代之后, 确保了稳定性之后才会进入到RHEL中的

因为老版本的软件虽然没有一些新的特性, 没有特别fancy的效果, 但是, 毕竟经过了多年的实践检验, 是切实可用的.

并且, 除了Fedora的试验场之外, Redhat还有大量的QA员工来做对每一个RHEL的发布做大量的测试(最终都会进入到CentOS), 还有一个硬件兼容性的团队来专门保证每个RHEL的硬件兼容性, 这些都是RHEL/CentOS作为一个生产系统的操作系统所必须的, 所有的这一切, 都是为了追求生产系统的稳定可靠.

Redhat内部是把团队分成Project 和Product两部分的

project的team就专门工作在开源社区, 自己搞自己的

product team则会基于某个project的release再进行测试(功能测试, 性能测试, 兼容性测试等), backport fix,文档等工作, 最后作为产品提供给付费客户

举个例子, Hibernate 社区版发布了4.0, 但是产品化的hibernate并不会跟进的, 还会停留在3.5

等4.0的社区版经过了一段时间的用户反馈(这个的反馈是很高效的, 因为社区中用的人很多, 社区的JIRA基本上每天都会有很多JIRA被open, 包括bug, 不兼容等等问题), 然后发布4.0.1, 再反馈, 再发布4.0.2, 再反馈, 再发布4.0.3

这时候, 经过了几次的社区反馈加bug fix release的迭代之后, 基本上4.0这个大版本的问题就会都被发现了, 然后, product team就开始介入了, 他们还会有专门的QA再做更详尽的测试, 然后按照不同的需求, 看是可以只做bug fix backport 还是需要把某些用户需要的new feature也port到老的3.5上, 然后发布一个3.5.1 的产品

可以看到, 一个产品的艰辛诞生历程.....

所以, 如果你们有足够的人力和资源来对新的版本的软件来进行足够的测试, 并且再发现问题的时候有能力能自己fix(假设都是使用的开源软件), 那么追求新版本没有问题(但是就不要说节省成本了, 这些是需要消耗大量成本的), 如果没有这个能力, 还是老老实实使用别人的成果吧

注: 前Redhat员工