案例

汉得信息

更好的用户体验

icon

概览

汉得成立至今,作为一家在咨询实施行业服务超过20年的企业,服务各行业的客户超过3000家,业务领域已扩展至全面的企业信息化应用产品研发、咨询实施与技术服务,从智能制造到互联网行业再到传统的服装零售等方面都有涉及。随着IT技术发展和经营环境的不断变化,企业表达出越来越多的个性化IT诉求。“当需求越来越多样化,什么样的方式可以更好更高效满足客户需求?”是我们一直关注的问题,我们希望能以更高效稳定的方式实现客户需求。“传统的软件开发方式,当开发过程中新人比较多的时候,经常会因为环境导致编译发布过程中出现问题,很多时间消耗在上面,而且往往这些问题出现的时候,需要一些经验丰富的人去解决,最后却发现很多问题都是因为环境的不一致或是很小的差异引起的,想达到高效,我们知道必须做出一些变革。”汉得研发中心总经理张礼军说。

挑战

“企业内部要构建业务快转型创新的平台,它必须具备刚才所说DevOps,微服务以及容器技术,才能满足一个企业内部这种业务创新对技术平台的要求,所以我们基于这些,也可以说相当于把支撑我们自己研发团队本身的能力转变成了一个平台的能力,逐步形成我们所讲的一个数字化平台——PaaS平台,总的来说,就是把我们内生的需求逐渐演变成了一个产品,为其他客户提供PaaS解决方案。”张礼军说。

碰撞

IDC曾对2000位跨国企业CEO做过一项调查,结果显示其中有67%的人认为,截止2017年底,数字化转型将成为所在企业的战略核心。预计到2018年底,全球有超过50%的大型企业将拥有完善的数字化转型战略。互联网已经带来了新的经济形势,在以技术为核心的商业模式下,我们必须要不断激发自己的潜能,而数字化转型的本质,就是通过技术变革来释放价值、激发潜能的过程。

故事发展

“一开始我们的服务架构是基于MVC的HIP架构,但是随着业务的快速变革,我们渐渐发现需要微服务这种架构配合我们的敏捷团队,来进行快速创新,我们做了很多DevOps相关的敏捷变革,自然而然促成我们在软件架构这一块也要进行一个变革,所以才开始从HIP演变去做HAP cloud,但是HAP cloud框架做了之后,我们发现在企业内部这种转型创新,光有一个开发框架,是很薄弱的不足的,如果企业内部要做这种业务转型,他需要一个相当于企业内部私有PaaS平台,首先要有微服务独立快速迭代这种系统功能的开发框架,但是要作微服务交付的话,我们又发现如果没有相应的DevOps的工具链来支持,也是很难交付的。

解决方案

说到工具链,我们在工具上是一个逐步演变的过程,比如说持续集成,就用过很多工具,最初的工程实践用的Jenkins,后来随着服务架构转变,发现Jenkins的特性并不适用于DevOps的流程,我们逐渐开始把基于GO语言实现的gitlab CI作为持续集成的工具。微服务架构,服务数量很多,如果按照原有方式,很难管理,但是容器技术恰恰可以解决这些问题,我们考虑过swarm,Rancher,Mesos,因为考虑到语言和开发工具统一,以及灵活性等各个方面综合考虑,最终决定引入kubernetes来解决微服务架构所带来的问题。

"在数字化转型的大背景下,我们一直也在寻求一个更好的软件开发方式,缩短我们的开发周期,更快地交付。我们是在做devops转型,但其实我们Devops转型过程是'不正统'的,回望这个devops转型,并不是有意去做转型,而是真的发现了很多传统开发管理过程中存在的问题。"

- 研发中心总经理 张礼军

IDC曾对2000位跨国企业CEO做过一项调查,结果显示其中有67%的人认为,截止2017年底,数字化转型将成为所在企业的战略核心。预计到2018年底,全球有超过50%的大型企业将拥有完善的数字化转型战略。互联网已经带来了新的经济形势,在以技术为核心的商业模式下,我们必须要不断激发自己的潜能,而数字化转型的本质,就是通过技术变革来释放价值、激发潜能的过程。传统的瀑布模型强调预见性,各阶段之间具有很强的顺序性和依赖性,前一阶段的工作结束后才能开始下一阶段的工作,经常在规定时间内只有40%的项目能成功交付,而且开发时间如果过长,留给测试时间不够,质量上就无法得到保证。这种模式下越晚集成越容易失败,有时候实现的50%需求,无用需求占比却高达60%,很大一部分时间都浪费在没价值的事情上。

“我们是以寻找解决方案为出发点,比如说,我们经常会有这样的体会,当开发过程中新人比较多的时候,常常会出现环境方面的问题,比如编译发布等等这些方面的问题,很多时间消耗在这种事情上,而且往往这些问题出现的时候,需要一些有经验的级别比较高的人去解决,最后你可能会发现很多问题都是环境的不一致或是很小的差异导致的。”张礼军说。我们想要找一些解决方案避免或解决这样的问题,开始尝试一些持续集成的工程实践。

“一开始我们的服务架构是基于MVC的HIP架构,但是随着业务的快速变革,我们渐渐发现需要微服务这种架构配合我们的敏捷团队,来进行快速创新,我们做了很多DevOps相关的敏捷变革,自然而然促成我们在软件架构这一块也要进行一个变革,所以才开始从HIP演变去做HAP cloud,但是HAP cloud框架做了之后,我们发现在企业内部这种转型创新,光有一个开发框架,是很薄弱的不足的,如果企业内部要做这种业务转型,他需要一个相当于企业内部私有PaaS平台,首先要有微服务独立快速迭代这种系统功能的开发框架,但是要作微服务交付的话,我们又发现如果没有相应的DevOps的工具链来支持,也是很难交付的。

Choerodon的使用确实在很大程度上缩短了开发周期,加快了迭代的速度,大大减少了开发运维人员的负担。

说到工具链,我们在工具上是一个逐步演变的过程,比如说持续集成,就用过很多工具,最初的工程实践用的Jenkins,后来随着服务架构转变,发现Jenkins的特性并不适用于DevOps的流程,我们逐渐开始把基于GO语言实现的gitlab CI作为持续集成的工具。微服务架构,服务数量很多,如果按照原有方式,很难管理,但是容器技术恰恰可以解决这些问题,我们考虑过swarm,Rancher,Mesos,因为考虑到语言和开发工具统一,以及灵活性等各个方面综合考虑,最终决定引入kubernetes来解决微服务架构所带来的问题。

对于服务的管理、发布,当服务越来越多,一个数据中心必须要有相应的持续交付来配合,同时为了更快做好应用的部署,我们要实现从infrastructure层来屏蔽它的复杂度和统一它的标准,企业内部要构建业务快转型创新的平台,它必须具备刚才所说devops,微服务以及容器技术,才能满足一个企业内部这种业务创新的技术平台的要求,所以我们基于这些,相当于把支撑我们自己研发团队本身的能力转变成了一个平台的能力,逐步形成我们所讲的一个数字化平台——PaaS平台,总的来说,等于把我们内生的需求逐渐演变成了一个产品,为其他客户提供Paas解决方案。”张礼军说。

我们现在已经在使用自研发DevOps平台——Choerodon,DevOps项目负责人说,平台工具的使用确实在很大程度上缩短了开发周期,加快了迭代的速度。单体运用场景下,耦合度很高,开发和维护的成本很高,稳定性不好,很容易牵一发而动全身。比如:“我们之前是采用手动部署,需要配置各种参数,几个参数的时候还好,当配置项数目有十个或者几十个的时候,是很容易出错的,花费了大量时间查找部署失败的原因,可能只是因为环境参数没有注入。”时间成本很高,现在我们部署的时候,就不需要考虑这些配置项,很大程度减少了开发运维人员的负担。

“我们将DevOps平台放入我们的解决方案中”张礼军说。旨在帮助企业如何实现快速转型。现在已经开始与一些客户合作,帮助他们加快转型的速度。我们并不是把DevOps转型当成一种目标,因为对于传统应用来说,并非全部都适合,如何快速实现转型才是最终主旨。

在部门本身,正在进行着DevOps的转型,我们也正在寻求说服更多部门转向基于该平台的开发和工程实践。“我们有很多软件开发人员,我们会为他们提供我们的平台作为服务解决方案。”他说。“希望在他们的迭代周期中可以看到明显的削减以及开发运维一体化的真正实现”。

张礼军认为这个平台还有很大的发展潜力。首先,他希望完善平台的自动化测试以及开发监控,这对于一些客户来说非常重要。

“我们不仅是供应商,同时也是用户,使得我们可以在用户的角度来看待这个产品,总结我们自身在使用过程中遇到的问题,总结经验,不断对产品进行持续优化,相比于只作为开发者,我相信会带来更好的用户体验。”