DockerInfo大家好，以下是我作为使用者就中英人寿保险有限公司基于容器技术的实践做一个分享，内容分以下四个部分
以下主要分享中英人寿IT如何针对自身业务特点，应用和推广容器技术。IT根据不同用户群体的特点，有针对性的选择容器优势进行宣导，从而使容器技术的应用和推广更加顺利。
保险公司业务复杂，同时中英人寿是中外合资企业，外方股东对于经营管理特别是信息技术的管理有诸多制度上的要求,审批复杂繁琐，推进新技术应用有诸多桎梏。 金融企业在IT技术使用上相对谨慎，加上繁多的规章制度和部门，新技术的应用和推广，往往困难重重。如何说服用户与管理层，打破传统观念，并合理控制风向都是IT在应用新技术上必须充分考虑到的。
系统架构复杂：应用系统都不是孤立的独立系统而是前中后台各种服务组成的一个时时运行的业务体系。一个标准的互联网服务会涉及前台展现，客户身份认证，时时数据查询，各类标准业务流程，支付通道，甚至包含在线核保，保全，理赔，图像处理，各类通知服务和各种服务质量追踪认证。
业务规则复杂：寿险业务逻辑普遍复杂，因寿险产品的复杂程度和特性化越来越高，产品种类一般都在数百种，通用业务规则数千条，还包含更加复杂的医疗健康规则，以及长期险的给类保全类给付规则，更何况还有理赔的规则
管理制度众多：保险公司内部管理制度众多，涉及监管，合规，风险控制，信息安全及日常业务规则和信息技术及开发运维相关的各类制度。如中英这样的中外合资公司和包含了股东方的各类信息安全和数据安全管理要求。为了满足各类管理制度要求，系统设计的灵活性大大受限制
需求变更频繁：各类规则不是固定的，而是不断增加的。随着服务，产品和各类业务活动的增加，对系统功能，业务规则的要求不断增加。且这些前后规则大部分不是替代关系，而是叠加的，均需要通过系统的支持来实现
需求变更频繁：各类规则不是固定的，而是不断增加的。随着服务，产品和各类业务活动的增加，对系统功能，业务规则的要求不断增加。且这些前后规则大部分不是替代关系，而是叠加的，均需要通过系统的支持来实现
基础架构负担：数量众多复杂的业务系统对基础架构带来了极大调整，无论是服务器，网络，存储还是信息安全方面，运维的负担越来越大
实际业务需要：3个月内必须完整2个移动应用的开发和上线，并能确保足够的性能和扩展性
效率的需求：
1.基础架构要在满足安全性的基础上保证足够的弹性扩展和性能
2.整体业务需求定稿预计要在启动一个半月以后才能完成，留给IT建设的时间不足2个月
3.涉及多个业务团队协同，开发团队包含北京广州的4个团队，各有分工但又需要能协调快速推进，并能及时看到开发的阶段性效果
成本的控制：
1.项目投入成本固定，长期投入可能会有很大波动，初期的基础投入必须控制
2.整个项目的基础投入的采购时间必须配合项目的开发周期
3.运维人员不足，短期无法新增运维人员，必须最大化利用现有人员
容器技术从2015年开始关注，随着容器技术的快速发展在2016年从推广使用角度都相对成熟。但作为一种新技术，如何能让一个相对传统，同时又有众多规章制度的金融行业公司使用，依然存在众多困难。具体使用人群和管理人群对容器的理解成为推广容器技术的关键新宿。重点人群的推广和理解困难程度远高于技术的使用本身，但正因如此更不能回避可能存在的最大阻碍。想要成功推广必须能把阻碍变成动力。
从寿险业务特点可以看出，系统架构和业务规则的复杂，迫切需要标准化来简化开发和运维自身的工作量。因此容器在CI/CD上的优势，成为向开发和运维部门的实际执行人员推动容器技术的重要抓手。
自动化，隔离和集中管理的优势，更多体现在管理上。这点在项目执行和上线后，逐步体现出期优势。项目执行过程中向管理人群介绍其相关知识和优势，成为今后进一步全面推广容器技术的重要抓手。
基于公有云的容器方案不一定在整体上降低成本，但其在成本控制灵活性上有很大优势。同时随着容器技术的发展，目前容器的稳定版本对于实际应用来说已经完全可以承受。特别是目前容器的商业技术支持，让不具备太多容器开发经验的用户也可以快速使用容器技术。在控制成本上有以下几个特点。从实际使用效果上看，设备采购到货到安装的时间从传统的按月计算，到现在基本忽略采购时间。部署上基础操作系统安装在云上忽略不计，环境部署在配置基础镜像的基础上基本是分钟级别的。这已经满足我们的使用要求。
为了能把容器技术的优势最大体现出来，项目本身是一个全新项目，避免过多历史包袱和其他相关问题。在项目实施过程中，采用公有云部署加快了环境部署的速度，容器的使用在这个项目中是彻底的。同时基于数据安全性的考虑，项目中所有数据均不落地，均采用redis加载。在设计之初首先避免在安全性上收到过多传统规章制度的质疑，避免浪费过多时间在解释和说明上。同时不过分强调测试自动化，尽量保持原有的测试流程和方式。在使用用户层面基本感觉不到改变。避免了过多的沟通和解释。
自动构建，代码管理和版本管理都实现自动化和可随时回滚。让运维人员充分感受到了容器技术的优势。同时在服务器使用上利用率有极大提升，基本上减少了近一半的服务器要求。同时考虑到今后容灾和系统扩展的要求，本次公有云部署只使用公有云的基础服务。所有项目内应用均以服务形式独立运行在容器下，从而做到充分的隔离。减少对公有云服务的依赖，并确金融行业业务系统容灾的要求。如有任何故障均可以在企业内部及时恢复完全相同的生产运行环境。
在整个项目实践中，采用成熟的持续集成方案，并全部部署公有云的容器中。最大限度避免了技术上的挑战，整个项目中除了ELK的使用，由于经验不足环境配置的性能不佳需要调整外，整体上都执行顺利，未遇到太多技术困难。但在容器使用中还是遇到了一些特殊问题，因此寻找一个有经验的合作伙伴来推动容器，对于金融企业IT来说是非常重要的。不建议准备不充分，仓促上马。
容器技术应用和推广的关键是实际使用人员，因此IT内部对容器技术的认识程度非常重要。IT团队的参与必须是实际的参与，开发，运维和测试环节人员都必须参与。推动这类项目首先是IT内部管理者的认识问题，只有管理人员本身认识到容器技术的优势和迫切性，才有可能真正进行推广。纯技术人员的喜好，很难让容器技术得到真正有效推广。
实际应用必须循序渐进，不要过于追求先进性和完美。必须从自身能力出发，量力而行。在实际应用中最好要找到一个成熟的合作伙伴，必须讲容器技术是一种新技术，对于金融也IT来说更多专注的不是不断变化的新技术而是业务与技术应用的结合。因此为了少走弯路，成熟的合作伙伴是非常重要的保障。
运维自动化需要流程制度的配合，工具不能代替人员自身的管理要求。虽然自动化可以提高基础配置的效率，但真正提高效率的是开发和运维人员观念的转变。因此这个过程必须不断总结和修正，寻找问题和察觉。不要认为上了docker就一劳永逸，实际上真正开发和运维会遇到更多新的问题，因此必须正视面对这些问题。
由于容器技术和相关CI/CD技术的发展速度非常快，因此在应用推广中，负责人对技术方案的把握非常重要。尽量避免在同一个项目中采用过多从未尝试的技术或者版本，必须控制新技术尝试的范围，从而控制整体实施的风险。这实际是追求创新和稳定之间的一个权衡，负责人在实施中要避免过多受外界因素的影响。
同时必须考虑运维人员的工作负担，容器技术更多是对运维人员工作的改变，实际是要掌握更多新的知识和尝试更多新的技术。因此在项目实施中实际运维人员的工作量是增加的，这点必须考虑到，否则会得不偿失。
好了，以上是我对前期中英在容器方面实践的一些经验分享，谢谢大家。
