娱乐棋牌

复工大势下,远程办公的科技企业只能“坐以待毙”吗?

YUANBIAOTI:FUGONGDASHIXIA,YUANCHENGBANGONGDEKEJIQIYEZHINENG“ZUOYIDAIBI”MA?

作者 | 张伟、胡姝琦、张烁

责编 | 郭芮

图 | CSDN 下载自视觉中国

2020 年,每个中国人都正在度过一个不同寻常的春节,疫情来势汹汹刻不容缓。国家启动重大突发公共卫生事件一级响应机制后,按照疫情防控的具体安排,每天进出公共空间的人员都需要测量体温,而民生类的生产制造企业又不得不提前复工解决社会紧缺的物资以保证民众的生活稳定,而随着之后即将到来的复工潮和复学潮,如何实现在安全的前提下帮助企业和学校复工复学的工作迫在眉睫。市场上急需一款简单、易用并且可以快速实施的解决方案,去帮助企业更好地记录员工的体温与身体情况,保障企业的安全生产,也可以让园区管理人员随时监督到企业的管理与落实情况,最大化的降低人员的精力与成本。

对于此需求,起硕实验室的团队成员们立刻递交上了属于我们自己的“请战书”,自告奋勇的承接下了这份艰巨的任务。时间就是生命,全国都在与疫情赛跑,与时间赛跑,雷神山与火神山可以在 10 天之内平地而起,堪称中国速度的奇迹,那我们又为什么不可以?如何短期内又快又好的开发出“智能防疫复工平台”便成了现阶段最重要的使命,不但要短期内迅速上线,还要简单易用,让更多的人可以轻松的上手,要能支持大并发的数据请求,更要可以快速的更新迭代版本以便应对随时都在变化的疫情与政策,这便成了我们这个团队在接下来的日子里每天都要面对的挑战。

时间进度

2 月 2 日正月初 9 本来应该是每年返程复工的第一天,政府为了保障市面上的口罩供应和基础的民生服务,有部分企业已经提前的开工,预计即将迎来的大批企业复工潮则推测是 2 月 11 日左右。而我们收到通知的那一天是 2 月 4 日,于是满打满算留给我们的开发时间仅有一周左右,我们需要在短时间内理清政府部门的诉求与工作流程,并且快速的提供并落地出一套简单可行的解决方案。

那还等什么,我们说干就干,时间就是生命,我们要全力以赴的与时间赛跑,跑赢就是胜利!

7 天过后系统顺利上线,正式投入市场为 1 万余名员工服务,为了迎来第二天大批的复工潮,我们还紧急的进行了服务器升级,以免因为早高峰出现的集中打卡上报情况而造成服务宕机。

之后的几天时间,我们又因为疫情的发展与政策的调整,及时的根据需求支持复工平台的功能变更:从支持医疗物资企业复工增加到支持二产复工、三产企业复工,从重点疫情地区人员的筛选排查和隔离信息监控,升级为中低风险地区返回人员的两点一线排查,再进而扩展到防外籍输入性疫情传播的重点人员监控,这些功能可以有效地根据不同人员的属性进行不同级别的检控力度,也在保证了生产安全与人员安全的情况下,最大力气的推进企业复工复产。

为什么效率很高?

项目目标明确,团队高度认可

我们的客户是天津市新冠状病毒收治点周边工业园区,该管委会管辖了下属 240 多家的二产企业,和近 1000 家的三产企业,在疫情期间,该工业园区内有部分企业主要是生产疫情保障物资,他们在疫情期间内也是全面复工并加班加点赶工,努力多生产一些类似于口罩和防护服之类的物资,但是如何保障这些园区内的企业平稳有序的复工,减轻园区管委会的工作压力,可以在较短的时间内上掌握园区各个职工的每天身体健康情况,是我们团队工作关注的重点。

经过我们梳理,该平台的整体结构大概是这个样子的。

后来经过我们的讨论,发现访客的小程序优先级没有那么高,那么这个小程序的需求先砍掉,所以我们的目标就变的很明确,在一周的时间内,上线一个复工应急通的小程序,同时配备相关的后台管理系统。助力疫情生产物资企业的复工,也就是等于间接的为疫情的防控尽一把力,所以大家的目标明确,积极性也很高。

临时组建老干部研发团队

因为 2 月 4 日天津市还属于未复工的状态,所以很多人还处在居家隔离的状态,所以为了支撑这次紧急的项目,由起硕公司牵头,联合其他公司的技术力量合作,临时组建了一个由有经验的中高管组成老干部研发团队,团队共有 6 个人,每个人平均的工作年龄在 7 年以上。因为疫情期间隔离的需要,团队的全部成员都是居家远程办公。我们真正的想做一个小而美的团队,做一个小而美的产品,奉献给一线真正需要的用户。我们的研发人力配比是这个样子的:

团队内部高效的沟通

因为疫情期间,大家都是居家办公,如何做到不在同一个城市的这些人,能够保持办公室办公一样的高效沟通呢。我们这边分享一下我们的经验:

雷打不动的项目站会机制

从这个项目的第一天,完成项目启动会起,我们就确定了项目站会机制。和敏捷中的项目每日站会不同的是,我们把站会的频率提高到了一天两次。早晨 9:00 一次站会,主要是明确当天的团队目标,个人目标都向团队目标对齐,同时同步风险和配合,这样每天先把信息进行了拉平。到了晚上 6:00 的时候,我们会再开一个站会,目标是回顾今天工作的进展,遇到的问题,接来下开展每天下半场的

用产物来说话,尽量不沟通

其实沟通的目标是信息传递,而不是频繁的电话、视频、语音沟通。所以我们认为最高效的沟通,不是时时在线,而是对方给你一个眼神,你就明白什么意思了。在复盘的时候,发现我们每天除了例会的时候,基本上不用太频繁的沟通,因为我们工作产物,已经传达了必要的信息。

1)产品 to 研发:

这是我们产品原型的部分截图,原型标注很详细,包括各种异常的状态处理,所以研发在拿到这样的产品原型时,基本就明白了,不需要再专门开一次产品需求会,节省了大量的时间。

2)后台 to 前端:

下图是我们部分 swagger 的截图,我们每个字段都有详细的注释说明,所以在前后端在进行接口联调的时候,基本上看协议就可以了,也不需要做太多的沟通,最优的时候一次沟通都不需要,就可以完成模块功能的开发。

3)研发 to 测试 to 研发:

同样我们以产品原型作为沟通的媒介进行产品功能的测试。为了快捷的目的,我们使用 Leagoo 的看板来记录 Bug,同时记录了相关的错误参数,这样研发看到 Bug 以后,直接修复。

成熟的工具支撑

工欲善其事,必先利其器,这样的道理大家都懂,可是在实践中如何提高个人研发效率,提高团队的产出,我们这里介绍下自己的小经验。

如何尽量少写代码,完成需求开发

首先,我们在团队中有一个理念,就是尽量的少些代码,对于一个需求,如果需要复杂的逻辑去实现,我们做的第一件事情不是立马实现,会想太麻烦了, 有没有简单的方案?本着懒人的思想,我们重点安利一个后端的框架,mybaits-plus ,这个框架的代码生成会做的更完善一些,从 Entity、Param、Vo 到 Controller、Service、ServiceImpl、Mapper 等代码都会自动生成。有了这样的利器,让我们开发业务逻辑的时候,面对 100 个表和一个表,所付出的基本工作量是一样,时间复杂度都是 o(1) , 下面是我们某一个业务中代码生成截图。

充满成就感的看板

在这次敏捷项目的开发中, 我们尽可能的使用了看板,而且创造性的把需求和 Bug 放在了一起,每一项任务做完了,直接拖动看板,同时在群里吼一下。通知相关的同事进行下一步操作。

而且我们的看板要求日清,所以每天早晨会看到看板上堆积的任务越来越多,但是到了一天结束的时候,看板的任务从左边移到了右边,心里就会带着满满的成就感去休息,第二天再周而复始,看板的每一条,实实在在记录了我们从无到有创造了一个产品的过程。

我们如何实践 CI、CD

我们目前的研发流程转移到了华为的 DevCloud 上面,所以就在 华为 DevCloud 上来实践我们的 CI、CD 流程。下午是我们在 DevCloud 上面配置的流水线。

1)持续构建:

我们使用代码触发器的规则,每次提交到 dev 分支的代码,都会触发一次构建,这样可以保证测试环境的内容是我们实施更新的结果,测试的同事随时可以测试最新的功能。从下面的统计可以看出,我们单日的构建次数,最高可能在 20 多次以上,所以每天减少20 次的系统登录和构建点击,也确实节省了不少的工作量。

2)持续部署:

为了保障系统高可用,我们在 Nginx 后面负载 n 台业务服务器,所以生活从环境的部署,我们也是通过脚本来控制,一次性部署N台服务器,通过减少人员的直接操作,提高安全性和工作效率。

项目时间的充裕保障

在项目的时间管理上,我们可以分享的可能只有两个点:

  • 做好个人的时间管理,因为大家都居家办公,怎么样协调工作和生活、已经家人之间的关系,每个人各不相同,但是从结果来看,团队中的每个人都能做到很好的时间管理。
  • 最大可能的保障项目上投入的时间,从目标确定到产品上线一周的时间内,大家基本都是凌晨 1:00 左右休息,早晨 7:00 多爬起来又继续工作了,即使有各种工具利器的加持,但是艰苦奋斗的作风也不能丢。

如何保障系统安全?

在尽可能端的时间内,上线一个可用的产品,但是并不意味着其他的方面就不管不顾,毕竟我们做的是一个实际使用产品,而且涉及到个人的敏感信息,一旦安全性问题处理不好,就会演变为事故。所以我们在系统的安全性方面做了下的考虑:

敏感信息处理

对于个人的敏感信息,我们做了两方面的处理。

1)防止系统被拖库、敏感信息加密存储

我们系统中通过注解的方式对核心字段进行注解标注,使用 AOP 的方式对民敏感的字段做了对称加密。

2)防止页面截屏导致敏感信息泄露

为了防止身份证号等敏感的信息在页面展示的时候,通过截屏的方式会把身份证号进行泄露,我们在前端页面展示会后也加入*** 处理。下图是一个示例。

3)尽可能操作日志留底

我们在系统中还尽可能的记录了用户的操作日志,防止有一些问题出现的时候可以进行追溯。

数据库安全性保障

在数据库安全性的方面,我们主要做了如下的考虑:

  • 禁止数据库的公网访问,保证只有 VPS 内部的机器可以访问数据库;
  • 设置数据访问的 IP 白名单;
  • 删除无用的用户,例如 test 用户;
  • 设置数据库访问的强密码。

接口服务的安全性保障

在接口服务的安全性方面,我们主要做了如下的事情:

  • 在阿里云上面申请了免费版本的个人证书,保证所有的 API 接口和管理后台,都使用https 的服务。
  • 使用 JWT 的 token 模式,token 信息做了多重的加盐处理。拒绝使用 freshtoken 的策略,保障系统的安全性。
  • 使用 shiro 的认证和授权,保证系统的用户只能在自己级别的范围内获取数据和管理数据。

如何保障系统的高可用?

系统压力估算

在系统进行生成环境部署前,我们对系统的压力进行了简单的估算,按照 4 万员工全部复工的场景,如果在极限情况需要再 1 分钟内完成身体健康情况的上报过程,那么系统可能面临的峰值 QPS 为:40 000 / (1 * 60 ) = 666.67, 所以为了保险起见,我们使用简单的分布式服务系统,一个 nginx + 两台业务服务器。

简单的分布式服务 + 数据库高可用

根据上下面的分析,我们最终的生产环境的配置如下图所示,在数据库的高可用和安全性方面,我们才用了华为云的 RDS 服务,配置了主备的服务器,保障数据的冗余备份和安全。

监控和告警机制

为了监控生产环境现网的运行状态,我们使用开源的 Zabbix ,对生产环境的服务器进行了监控,同事配置了邮件的监控脚本,如果发现现网的请求时间 > 1 秒钟,就会发邮件给相关的人进行提醒。下图是我们的生产环境的监控截图。

下图是我们收到的告警邮件。

在疫情期间,我们获得的那些肯定

2 月 18 日工业和信息化部办公厅又发布《关于运用新一代信息技术支撑服务疫情防控和复工复产工作的通知》,支持运用互联网、大数据、云计算、人工智能等新技术服务疫情监测分析、病毒溯源、患者追踪、人员流动和社区管理,对疫情开展科学精准防控;引导企业加强互联网应用能力,充分运用网上疫情防控资源和信息化工具,建立线上线下、联防联控的管理体系。

此时距离我们开发这解决方案已经过去一周时间,我们回顾这次经历时,发现其实可以将我们的经验分享出来,把经验与思考整理一套方法论来供其他企业参考,以便在接下来进一步的防控工作到来之前,大家可以借鉴我们的经验更快捷有效的搭建团队与产品。

与此同时,我们参加了很多的公开分享,也有幸参加了像 CSDN 举办《中国远程办公大考线上峰会》及谷歌开发者社区组织的《智能技术助理复工——疫情给制造业带来的基于与挑战》等线上活动,与大家交流我们这一阶段的心得与体会,我们也收到了大批媒体的竞相报道,得到了市场的肯定。

总结与思考

这个春节真的不一样,这世界仿佛被按下了暂停键,没有人再去关心春晚是否精彩,没有人再去走街串巷的拜年,没有了热火朝天的聊天聚会,没有欢天喜地的游玩逛街,我们低头看着手机里飞速上涨的数字,窗外是大喇叭广播反复不停的播着口号,电视里正在播着一个个的逆行者在与病毒奋斗的身影,这一切都在时刻提醒着我们,一场与新型冠状病毒的战“疫”正在打响,愈演愈烈,热火朝天。

与病魔较量之时,作为我们普通人,为配合防疫管理措施和号召,大部分人能做的只有主动更改自己的过年安排,退掉了回家的车票,大门紧闭足不出户,而在一线,则有人义无反顾的放下家庭与休息,选择回归岗位,或是与患者共渡难关,或是做着自己分内的工作,努力的维持着这个社会正常的运转。

而作为一个有着使命感的技术团队,我们无法安耐住心中的蠢蠢欲动,想用自己的双手为我们这个正在被经历着巨大考验的社会贡献一份力量。于是我们自告奋勇的联系了公司所在的开发区管委会,希望可以利用自己的开发能力,帮助政府人员解决在防疫过程中面临一些实际的问题,来降低他们的工作压力。

想要在一周的时间又快又好的完成一个产品的需求调研、产品设计、研发测试、生产部署等一系列环节,本身是一件具有挑战性的工作,而且在实际的工作过程中,快和好本身存在一些矛盾点,所以我们每个环节都在进行权衡和斟酌,在效率、质量、可用性等各个方面进行取舍。

但是最终的结果是好的,我们系统的系统已经稳定运行 1 个月,随着疫情的发展,已经陆续有 450 多家企业接入到系统中,各项工作也在有条不紊的进行当中。我们一周摸爬滚打的付出也得到相应的价值体现,使我们心理最感安慰的事情。

但是随着系统的运行,我们也逐渐发现了一些系统的弊端,也一一列举出来,供大家的参考,也为了日后的改进:

  • CI、CD 这一块没有进行自动化的测试,产品的测试功能,还是主要依赖于人工测试,这块儿确实有很多的工作需要改进。
  • 通过现网的监控发现,我们现在的 web 服务和 后台服务使用了同样的系统带宽,在虚拟机带宽吃紧的情况下,web 的一些 JS 文件加载较慢,所以后续可以考虑 CDN 的分发,进一步缓解带宽的压力。
  • 如果 4W 员工全部复工, 每天都要上报 3 次体温的话,那么记录表一个月的数据增长量为:4W * 3 * 30 = 360W,那么单表很快会达到 MySQL 单表性能的极限,所以数据的分库分表工作需要进一步优化。
  • ……

最后我们希望疫情早日结束,我们研发的防疫复工平台早日下线,让我们迎接美好的人间四月天。

作者简介:

张伟:天津大学计算机科学硕士、曾就职科大讯飞,拥有 8 年的一线研发经验,拥有 6 年的研发管理经验、目前担任起硕智能科技有限公司的CTO。

胡姝琦:起硕科技产品总监,产品及运营专家,在产品设计、产品管理、用户增长、产品运营、开发者关系等方面有较为丰富的工作经验。

张烁:起硕智能科技CEO,不设能力边界的创业者。返回搜狐,查看更多

责任编辑:

声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。
大家都在看
推荐阅读
今日搜狐热点
6秒后
今日推荐