汽车行业上云是一个趋势，一般来说有几大系统，生产制造系统，互联网新业态系统（ 车联网），还有一些企业门户。从现状来看，优先上云的是门户，其次是偏互联网业务系统，最后才是生产制造类的系统。一般来说，汽车行业的 上云需求的矛盾较为强烈，主要原因有几个，一是随着业务的持续扩张，多数据...

没有必要联系具体看业务场景对弹性和黑盒交付的需求另外资源利用率是另一个点，弹性看你基盘，因为对私有云来说这个是稳定的。当然利用更“合理”是必要的，这点靠人是不靠谱的

独立构建，涉及基础平台和上层服务。前者短期手工运维，但通过开发逐步自动化。后者通过开发实现。支撑人员和运营容器数量关系不大，但和上层开发服务的数量正相关。关键点：开发从上往下做。...

需要考虑多个层次，主要包括：容器主机：主机本身的安全设置、SELinux的启用、Cgroups和Namespaces使用等容器镜像：基础镜像使用、基础镜像更新和漏洞扫描等容器仓库：通过建立TLS仓库，并通过HTTPS绑定，这样Docker只能从授信的仓库获取镜像容器构建和部署：与正常CI/CD类似，但需要规避...

需要考虑下使用容器的初衷，究竟是业务的敏捷弹性需求触发呢还是交付复杂性需求初衷同时需要注意：资源利用率提升导致费用的节省、固定资产投资费用前后差异、人员学习成本及能力依赖差异、开源文化收益...

看业务受众。如果是面向企业，由于业务链路长，建议从顶层往下解构，到level3之后再考虑服务化（而不是微服务化），这个和成熟度有关如果业务面向C或业务链路短，可以考虑通过下层快速迭代演进。...

首先需要确认做容器的初衷是什么分析哪类业务需要容器化人员和组织定义：哪类人实施，开发团队准备好了么，运维团队准备好了么技术堆栈选型：涉及哪类容器平台docker/k8s等，配套设施做哪些实施方式定义：包括自建、外部partner等...

应用上OpenShift容器云平台后，确实会带来组织形式的变化。常见的有两种形式：构建虚拟化团队，由运维、开发、业务等团队的成员参与组建。组建实体运维团队，专门负责PaaS平台的事务，对企业内部业务开发团队提供统一的支持服务。细节可参考下面的文章:OpenShift与组织架构...

容器集群内部的实现，弹性什么的，可以做到对调用方透明，当然url什么会改变