《2017年互联网技术团队如何应对互金业务的多变和挑战.pdf》由会员分享,可在线阅读,更多相关《2017年互联网技术团队如何应对互金业务的多变和挑战.pdf(21页珍藏版)》请在三个皮匠报告上搜索。
1、互联网技术团队如何应对互金业务的多变和挑战不断产生新业务新玩法永远呼唤新团队/人的助力挑战技术人员需要稳定目标和成长曲线市场形势变化 监管形势变化 技术环境并非一马平川技术架构需要积累-有人熟悉新业务但跟现有技术框架不合拍?-业务变更,工程师的技术积累何在?-不支持HTTP?-不能搭设DNS?-合规和法务要求带来技术变更和用户成本?困惑?一个网络拓扑的例子一个网络拓扑的例子技术 人 组织结构和管理思路 提纲组织结构和管理思路演变按职能划分运营融产品渠道&营销控合规产品测试前端服务端存储端数据端运营融产品渠道&营销控合规运营融产品渠道&营销控合规组织结构和管理思路演变按业务划分运营融产品渠道&营
2、销控合规产品测试前端服务端存储端数据端运营融产品渠道&营销控合规运营融产品渠道&营销控合规产品测试前端服务端存储端数据端产品测试前端服务端存储端数据端组织结构和管理思路演变大中台小前台?前台业务业务业务产品测试前端服务端存储端数据端产品测试前端服务端存储端数据端产品测试前端服务端存储端数据端中台技术模块通平台统框架技术模块通平台统框架组织结构和管理思路演变权责更清晰 沟通成本低 技术有长期积累和更大话语权 更容易适应人员的进出边界清楚大于短期公平 权责明确大于表面上的节省 起名字很重要 做中台架构的同学有足够动力做出最优决定YES边界问题中台逻辑不要包含金融产品结构 中台逻辑不要包含运营流程
3、中台逻辑不要包含合规限制NOT原则组织结构和管理思路稳定性 服务量 业务支撑 业务响应可量化指标指标和自驱服务质量和业务满意度 是否能去除冗余运营流程 合规要求是否有其他满足办法 是否有公共架构能抽象 数据冗余和逻辑冗余 扩展性和架构隐患不可量化指标指标组织结构和管理思路运营流程引起更改 金融产品结构引起更改 合规要求引起更改 存在“通道”工程师 要求停服务升级 展现层修改涉及中台纪律组织结构和管理思路ASK WHY业务系统基础服务业务平台通用框架技术架构的“上升”和“下沉”业务优先 允许浪费 不同阶段不同取舍 必要时强推技术技术例子:一个交易状态机的变迁单库大事务分库+补偿分布式消息补偿框架
4、分库+补偿+放大差错检测分布式消息补偿框架+单入口12435放放收放推Virtual Dom vs Dom based技术取舍单语言 vs 多语言 Dubbo vs Protocol 权衡技术原则区分需求和场景 损有余而补不足技术熔断保可用,业务熔断控风险92%?95%?98%?None of Above?TPS?Latency?性能评估质量评估熔断思路基于区块链的网信通行证技术-业务和合规的区别上升,逻辑共性下沉-被动接受监管-主动适应监管顶层结构设计人概念抽象流程思维分布式架构前端框架融产品运营流程法务合规数据存储极限思维换个角度看团队,组织结构可以更灵活人业务驱动和技术驱动早期业务驱动,后期技术驱动 依赖中台架构的成熟 前台要理解和驱动运营流程 中台要理解和驱动金融产品设计 前台要沟通和预见合规要求所带来的成本谢谢