技术小白独立部署一套DataSimba，需要多久？我们的目标是：最多一小时！
2月7日，鼠年的最后一场「StartDTHackathon」（奇点云黑客马拉松）落幕。本季以建立数据基础设施的智能运维底座的蓝图为基，以提升DataSimba的运维部署易用性为直接目标，从计算引擎配置、服务启动检查、服务健康检查、离线任务内存分配等四个角度展开角逐。
奇点云黑客马拉松现场四个issue召唤神龙，「技术小白在1小时内独立完成DataSimba的部署」这个终极任务，究竟能不能实现？且看↓
提issue前先吃狗粮
「StartDTHackathon」本季议题依旧来自「吃狗粮」。
「吃狗粮」是奇点云DataSimba团队的传统艺能：团队每一位同学都作为真实用户，体验1~N遍DataSimba的里里外外角角落落。DataSimba到底香不香？咱自己先吃为敬。
围绕DataSimba的运维部署易用性，经过为期2天紧锣密鼓的「吃狗粮」，DataSimba团队毫不留情地提出了25个问题（其中3个问题已被研发同学们顺手fix）。
最终大家票选出4个议题来，由4个小组分头解决：
计算引擎自动初始化_BUG消消乐组服务启动检查_Simba必胜客组中间件、服务健康检查自动化_奥利给组离线任务内存分配优化_奇点F6组
这就是「蹲码部」吗？是兄弟就一起蹲着debug！第一题：计算引擎自动初始化
自动填充一点点，配置简单亿点点
DataSimba部署流程可以简化为4步：
计算集群部署管理集群部署PE（运维）管理平台配置Simba应用平台功能测试「计算引擎自动初始化」这个议题处于第三个环节——PE（运维）管理平台配置。
「BUG消消乐」发言代表清水介绍，PE管理平台的计算引擎配置环节原来需要填写7个大类，每个大类2-5个选项，假设用户是「熟练工」，每个选项只要花上不到30秒，整个计算引擎配置完也需要10-15分钟。资源组配置的情况类似，运维人员需要填写15个选项，整个动作完成需要8-10分钟。
选项多带来耗时长的问题，也为运维人员带来了挑战。传统的IT运维对网络拓扑、地址映射等技术非常熟悉，但对分布式计算引擎相关技术可能不太了解，需要逐一理解、熟悉、确认，还可能配置出错。
「BUG消消乐」组发现，其实计算引擎的配置项中80%是无需修改的，资源组的配置项中则有90%无需修改，何不把无需修改的部分设置为自动填充默认配置？
「BUG消消乐」组梳理了CDH、Apache、华为等5种（厂商）平台支持的分布式计算引擎版本，不同的引擎填充默认配置项，也搞定了资源组的参数自填充，无需运维人员再手动逐一填写。当加入新的平台，DataSimba将继续枚举，客户依旧点击选择即可。
优化前优化后计算引擎自动初始化、资源组参数自填充后，PE平台初始配置耗时从25-30分钟缩短为5分钟，效果拔群。
评委点评高级测试工程师元宵：技术实现难度不高，但以小白友好的方式巧妙解决了问题。成果展示和阐述非常好，作为第一个展示的组，能先简要地向大家介绍DataSimba的部署流程；对基础概念阐释清楚，非专业同学也能够理解。
第二题：服务启动检查
启动顺序无依赖，一键工具速检查
「吃狗粮」时不少同学提出，在DataSimba服务启动环节常出现规范建表（规范建模—可视化建表）失败的报错。
究其原因，「Simba必胜客」发言代表褚岩介绍，这是因为数据建模与数据开发有启动顺序依赖，它将导致：
部署复杂：服务启动必须按照依赖顺序，花上相当一段时间，方能部署成功。如果不遵循顺序部署，比如数据建模模块先启动，那时通信中间件远程服务对象为空，就必须要重启数据建模服务，才能解决问题。
排查困难：遇到上述问题时没有报错信息，运维人员很难察觉到问题，影响后续的用户体验；即使运维人员在可视化建模时发现问题，也没法快速定位问题，需要研发人员查日志、排查问题，耗时又耗力。
「Simba必胜客」修改了通信中间件配置，取消了服务之间的启动顺序依赖。此后，运维人员无需关心服务启动顺序，正常启动服务即可。同时，优化代码，自动检查通信中间件服务，服务出现异常时即反馈到前端，帮助运维人员快速定位问题，提升部署效率。经测试同学验证，应用部署时长减少为原来的1/5。
「Simba必胜客」组并不满足于此。
组员们一盘算，花4个小时开发（+调试）了一个服务检查小工具：
当运维人员完成DataSimba应用部署后，可以用这个小工具一键检查服务启动状态（而不再需要逐一检查服务启动情况），提高部署效率和用户体验。
评委点评高级质量管理专家牧然：这个服务批量检查的小工具有点「作弊」，在提升用户体验感上有四两拨千斤的意思，确实很加分。解决服务启动依赖问题的呈现上，用前后对比视频展示，也很清晰。
第三题：中间件、服务健康检查
告别手动排查，拥抱自动探查
服务启动后，排排坐等调用。如何让服务调用更聪明、更高效，就是「奥利给」组的议题。
运维人员通过查看服务进程和服务端口可知，服务确实启动了，但不知道服务能否正常调用——接口并不会直接把非业务的异常信息直接吐给用户，得真的等用到才能知道，比如，登录时正常，用到某个功能时却发现报错。
「这时候你找后端同学看代码，确认代码有没有问题，如果代码没问题，再去看涉及到哪些中间件，这些中间件有没有问题。是中间件自身出错，还是服务与中间件的连接出错？」「奥利给」组发言代表老君说，「这一项一项手动排查下来，步骤繁杂，也考验技术。基本上每次都需要30分钟以上的排查时间。」
为实现中间件、服务健康检查的自动化，「奥利给组」写了一个批量服务检测的工具。
每个服务对外提供检测运行状态的接口，可以用于检测服务、中间件可用性状态。当DataSimba应用部署完成后，运维人员用这个工具就可以一次性批量获取每一个服务的可用性状态，检查所有服务及服务所涉及的组件是否正常运行，快速定位异常，一目了然。
中间件和服务排查时间从30分钟以上，缩短至10分钟内。
经工具检查，报告Redis有异常并返回异修复异常后返回全部正常评委点评高级测试工程师元宵：中间件、服务的健康检查自动化，对部署易用性提升上来说是非常关键的一项，这个题目有一定难度。不过我再提个升级的建议，目前还是全后端的呈现，如果能有个简单的页面，对用户会更友好。
第四题：离线任务内存分配优化
提升内存利用率，按需分配不浪费
在实际生产中，其实不同类型的任务对内存要求常存在区别，而以往DataSimba使用全局内存配置，这易导致：
#内存分配少了，有的任务不够用，会运行失败；内存分配多了，有的任务用不到，内存浪费。
#为了配合新任务的需要，经常不得不麻烦后台运维人员手动变更配置。而为了调整内存配置，每次都需要重新部署全局内存，单次重新部署就需要耗时约10分钟。
为解决上述问题，「奇点F6」组做了抽象配置文件，实现离线按任务内存的动态分配优化。由此，运维人员可以根据不同的任务类型，提前按需配置好内存分配，大任务大内存，小任务小内存。同时，当出现任务内存不够用或冗余的情况时，不需要再重新全局部署，客户的数据开发和运维人员都可以自行按需动态调整内存。
从10分钟缩短为不到60秒，充分释放了运维人员频繁的参数配置变更工作的同时，大幅提升了内存利用率和系统整体稳定性。
评委点评数据业务专家千景：过去不同类型的数据同步任务的内存常常是固定写死的，而需要改动内存的情况还经常有，每次调整都需要找后台运维修改，非常麻烦。这个改进可以让开发人员基于需求自己去动态配置，效率和体验方面的提升还是很明显的。
经过工程师们条理清晰娓娓道来、丝毫看不出紧张情绪的演讲角逐，综合结果展示、实现完整度、工作量和难度等考评维度，「Simba必胜客」组拔得头筹，获得由奇点云创始人兼CEO行在、DataSimba团队负责人地雷联合提供的奖金元！
逐渐被遗忘的终极任务
还有人记得我们的终极任务吗？我们的目标是「技术小白要在1小时内独立完成DataSimba的部署」！
伴随着各组成果的实施，非技术出身的产品经理荧惑扛起了这个挑战。在众人的围观之下（有一种老师们围观你考试的感觉），荧惑耗时30分24秒完成了DataSimba的独立部署，比预期目标还缩减了50%的时间，为本季黑客马拉松画上了一个漂亮的句号。
「幕后黑手」还有话说
谈到本季StartDTHackathon为什么选择从运维角度入手，DataSimba团队负责人、「幕后黑手」地雷谈到：
最近云原生概念非常热。如果一句话解释云原生，就是重构私有部署软件的架构，结合云服务的特点，节省客户的成本。在讨论中，业界经常会盯住存储和计算的节约，却没意识到运维的成本。
如果我们对运维做一下划分，可以划分为以下4个阶段：
阶段一、手工运维，在各种界面上点点点，到机房里一台机器一台机器地安装和升级。
阶段二、脚本化运维，利用CLI工具和基础脚本执行批量重复操作。
阶段三、自动化运维和持续集成（CI/CD），利用devops基础设施和最佳实践，建立一整套体系，把运维本身标准化、配置化、代码化、自动化，并持续迭代。
阶段四、智能运维（AIOPS），利用前一步规范化基础设施收集的数据，训练AI算法，实现事前预测、主动报警和无人运维。
互联网公司在运维方面的实践已经走得很远。例如，阿里云实现了1个运维工程师管理台机器；再例如，Google的算法可以提前预警某个机柜的硬盘故障率会在接下来几个月升高。
而传统行业随着数据化转型的深入，也开始面临运维复杂度方面的挑战。
根据我们的观察，大多数企业的IT运维还在脚本化、自动化运维的建设阶段。DataSimba团队的这次黑客马拉松，是我们协助客户建立数据基础设施的智能运维底座的roadmap的一部分。随着客户运维设施的标准化、配置化、代码化、自动化，客户运维日志数据的规范和积累，今后的某次黑客马拉松也许可以玩一玩AIOPS。
另外，我要强调的是，我们的黑客马拉松有自己的味道。你可以发现4个小组的观点，都是站在客户和合作伙伴的视角，很有产品感，不空想和自嗨。这和奇点云的基因和思考方式有关。