邯郸小团队要不要上容器部署，先看这三点
邯郸一家软件公司的老板前些天问我，小团队要不要上容器？我一般这么答：先看你有没有被部署问题折磨过。项目少、改动少，传统部署完全够用。项目多、环境经常不一致，容器才显出价值。技术是为解决问题存在的，不是为好看。丛台公园里的丛台，距今 2000 多年。
项目数量够不够
项目只有一两个，容器带来的收益有限。它解决的是多项目环境隔离和部署一致的问题。项目一多，手动部署就容易出错。这时候上容器才有意义。我们的经验是，3 个以上项目再考虑。数量不到，收益不明显。丛台区、邯山区的初创团队，多数是两个项目起步。
项目之间的依赖冲突也是信号。两个项目要求不同的运行环境版本，装在一起就打架。容器能把它们分开，互不影响。这种情况出现频繁，就值得上。冲突频繁，说明该分层了。
人会不会用
技术选型要看团队能力。没人会用，再好的工具也会变成负担。不是要求每个人都会写编排文件，至少要有 1 个人能处理常见故障。磁县一家做系统集成的公司，也是这么判断的。人手不够时，简单方案往往更可靠。
学习成本也要算进去。上手容易，出问题时排查难，这是容器常见的特点。网络、存储、日志三块的排查思路都要重新学。预算一段时间，别指望一上就顺。
运维成本要算清
容器不等于省运维。它把部署的活减少了，把集群运维的活加了进来。整体是省还是不省，要看项目规模。小团队如果只省了一点部署时间，却多了一堆新问题，那就不划算。算清楚这笔账，再决定要不要上。邯郸做软件开发的公司不少，选型这件事更要务实。
常见问题
容器能省多少部署时间
看项目数量。项目多了效果明显，只有一两个时差别不大。
要不要学编排工具
团队里至少 1 个人要会。其余成员掌握基本操作就够用。
上了能退回传统部署吗
可以，但要提前把配置和数据保留好，别只依赖容器里的状态。
邯郸的小团队判断该不该用容器，看项目数、人员能力和运维账这三项。为解决问题而选，不为选而选。你那边项目的数量和现有环境是什么情况？要动手之前，信服无限邯郸建议先按你的实际情况排一遍优先级。