大家以为从此以后可以松口气，但事实恰恰相反。原来攻坚战组成的组员陆续回到原来的部门，ERP项目组只剩下IT部门的人，“攻坚战”的胜利很快遭到了质疑。因为新系统大家还没用熟，在细节上总出现一些问题，大家对新系统的埋怨也开始越来越多。ERP上线后，失去了最初的赞扬和掌声，反而面临了很多困难与痛苦，那么如何克服这些困难？有什么良药能医治ERP上线后的困扰呢？
1. 特征处理模块管理 user 和 item 的实时和固有特征，并根据线上的反馈更新实时特征，比如：用户画像、浏览记录等。为了不同训练的实时性，实时样本生成服务和离线样本生成任务利用特征处理模块管理的信息生成样本，输出到离线或者在线样本存储中。
历史悠久的大型企业，都会存在遗留系统。这些系统运转着重要的业务，但使用到的技术已经跟不上时代潮流。因此有着维护成本高、难以扩展、用户体验差等缺陷。最终，企业一定会下决心开发一套全新的系统来替代遗留系统。除了完成新系统的开发，还有一项重要的工作，是将老系统中存留的数据迁移进新系统，也就是我们常说的数据迁移。如果你没有数据迁移的经验，很容易低估其难度。数据迁移看起来只是把数据从一个 DB 转移到另外一个 DB，select + insert + 转换逻辑就可以轻松搞定。如果带着这个想法开始数据迁移项目，你的团队很快就会坠入深渊，举步维艰。数据迁移是一项看似简单，实而复杂且繁琐的工作，想要做好并不容易。
Git版本管理库用于存放上线系统的 CM工程（Configuration Management，配置管理工程，后续会详细介绍）以及需要部署的业务系统。
什么是耦合？ 耦合，是架构中，本来不相干的代码、模块、服务、系统因为某些原因联系在一起，各自独立性差，影响则相互影响，变动则相互变动的一种架构状态。 感官上，怎么发现系统中的耦合？ 作为技术人，每每在心中骂上下游，骂兄弟部门，“这个东西跟我有什么关系？为什么需要我来配合做这个事情？”。明明不应该联动，却要被动受影响，就可能有潜在的耦合。 因为公共库，导致相互受影响，就是一个耦合的典型案例。 场景还原 一个看似“公共”的业务库(*.so *.jar *.dll *.php)，很多业务系统都依赖于这个公共库，这
中欧财富是中欧基金控股的销售子公司，旗下 APP 实现业内基金品种全覆盖，提供基金交易、大数据选基、智慧定投、理财师咨询等投资工具及服务。中欧财富致力为投资者及合作伙伴提供一站式互联网财富管理解决方案，自 2015 年成立以来业务持续保持稳健的增长。
嘉宾 | 廖子尧 编辑 | 邓艳琴 我想要兼顾性能和效率，这可能吗？美团平台或许找到了一个不错的答案：MBC 业务标准化容器方案。目前该方案已经大面积应用在美团平台业务，在千万级流量以上页面得到了验证：从方案上线起，在保持了原生体验的同时也为业务带来了 50% 的人力成本减少与 60% 的产研效率提升。 近日，InfoQ 邀请到美团技术专家廖子尧接受采访，他从零到一搭建了 MBC 移动业务容器的动态化解决方案。他还将在 GMTC 全球大前端技术大会（北京站）2021 分享该方案的搭建思路与已有业务标准化改造
微信作为月活过10亿的国民级应用，其安全能力备受关注。值得注意的是，没有足够的特征数据，安全策略将是"无根之木，无源之水"。微信安全数据仓库作为安全业务的特征数据存储中心，每天服务了万亿级的特征数据读写请求，为整个微信安全策略提供了可靠的数据支撑，是微信安全的一块基石。事实上，微信安全数据仓库不仅仅是一个存储中心，更是一个特征管理和数据质量管理的中心。本文将介绍安全数据仓库的起源、演进、当前的架构设计和数据质量保证系统的实现，请往下阅读。
很多同学，工作了五六年，都没有机会（也许是：不敢）独立负责一个完整项目的测试（独立负责一个项目测试后的上线流程，机会就更少了） 。
安全业务的核心逻辑在安全策略中实现。整个的策略开发流程包括特征数据的收集，安全策略的编写实现，和策略的反馈评估。其中特征数据的收集是必不可少的环节，数据的质量将直接影响安全策略的效果。
（六·一节快乐，花儿一样的少年） 目前公司项目偏多，平均每周五天基本上有四天都会有项目上线，有时一天会上线至少二个版本，就在昨天刚上线了一个项目，星期一才提测的一个项目，星期二就安排上线了，所以悄悄地告诉小伙伴们，昨晚俺加班了(再悄悄地告诉大家其实这个昨晚已经过去很久了~微笑脸)。 今天跟小伙伴们分享一下王豆豆公司的上线流程。 01 早会 每天早晨上班之后，都会开早会，早会主要是回朔昨天的内容、今天的计划、需要解决的问题三个方面。 开发每个人讲自己的情况后。 主持人：“测试呢？” 测试A：... ...
“在本环节中，已经不再涉及到SDL中的“工具”，转而向“流程”。产品发布前的最后一道关卡，做最终的安全验收。无论是否能满足安全质量要求，产品均有可能发布上线，但一定得有兜底的措施。”
互联网中一个项目的上线会需要各个工种间的配合，以研发为视角上会承接产品需求，下会交给测试验证，最终完成项目交付上线。其实除此之外，还会有业务、运营、UI设计、运维，来配合项目的发起、使用和运维维护。
作者：robinbinxie 腾讯CSIG工程师 01 引言 在目前的项目交付中，往往安全产品的部署，安全服务的实施都要“滞后”于整个交付进度。安全总是“最后”一个入场，就如同一道菜（项目）即将出锅，厨子顺手捏了把辣椒面（安全），顺手丢进锅里，再用铲子炒了炒，就出锅了。 这样看，安全产品和服务为整个项目服务和防护的作用人为滞后，在项目进场实施阶段，缺失必要的安全防护，导致出现一段安全真空。这些现状都给整个项目的安全交付带来潜在的风险，或许在当时不能及时发现风险问题，但就算项目交付给用户，那这种风险会随着
现在数据仓库层面的工作越来越多，开发人员也越来越多，如何保障数据准确性是一项非常重要的工作，，数据仓库的很多应用数据直接呈现给用户或者支撑企业分析决策的，容不得数据出现错误。随着开展的业务越来越多，数据模型越来也多,我们管控的越晚就越容易出问题。尽管有数据仓库建设规范，同样在数据模型命名，数据逻辑开发，每个人都可能不一样，而这些也容易导致数据模型准确性的问题。我们迫切需要制定一套数据的准确性验证流程，让大家都按规范流程来做，保障数据的准确性。
影响一个ERP项目的因素有很多，数据无疑是其中很重要的一项,正所谓“正确的诊断源于准确的信息，准确的信息基于可靠的采集”，当我们抓住数据这个根基，大处着眼，小处着手的时候，我们距离ERP成功的日子就不会太远。
清单的要素包括：什么人，在什么时间，需要准备什么资料，做什么事。其中，要明确先后顺序，要明确如何验证是否出现异常、明确验证方式以及问题处理方式。
重构的原因有很多，可能是伴随着业务的发展与升级，系统无法快速支持需求迭代，这时就有了重构的念头，一般情况下不建议对老系统进行重构，毕竟重构是有代价的。
项目组目前主要负责的一条业务线是一个数据管理平台。因为整个平台有很多个不同的模块儿，且每个模块儿对应着不同的数据提供方和后端服务，所以前端任务划分是按照不同的模块进行划分，当某一个模块的需求太多时，其他模块需求不多的时候，人员可以机动一下，帮助别的同学开发一下多出来的需求。
需求开发前，似乎业务同学提了很多明确价值点，比如 稳定性提升、减少开销 等，“看起来”很有价值。
在每一个互联网总不会缺少统一的API接口平台，公司级、部门级等等。存在即是合理，那么一个接口平台诞生的背景是什么，为了解决什么问题？怎么解决？
随着春天脚步的到来，2015年的信息化建设正式拉开大幕。移动技术在企业中应用，到现在这个时间已经不是什么新的概念，几乎所有的企业都把移动信息化建设放在了前3位的位置。大量的业务需求和应用APP被排进了计划，或正在建设，或已经上线不断迭代。然后，在如火如荼的移动信息化建设背景下，有三件事情不容忽视。 终端管理 计算终端的移动化的确带了极大的便利性，也为业务场景化提供了数字化可能。业务部门的移动需求与日俱增，APP的应用开发在绝大部分企业里排在了第一位。IT部门为了满足业务需求，往往先找了各种开发团
微服务的拆分一直是历史性的难题，行业内更是没有具体的拆分标准，拆分的好坏更多取决于拆分者的经验，并经过反复迭代，逐步优化、调整，以达到比较合适的划分。
需求调研奠定了整个系统和项目管理的基础，如果需求分析不够透彻，往往会导致系统及整个项目问题百出，甚至被马上丢弃。需求调研目的在于确定“做什么”即确定系统必须要完成那些工作，需求调研是去粗取精、去伪存真、由此及彼、由表及里的过程。
美团App、大众点评App都是重运营的应用。对于App里运营资源、基础配置，需要根据城市、版本、平台、渠道等不同的维度进行运营管理。如何在版本快速迭代过程中，保持运营资源能够被高效、稳定和灵活地配置，是我们团队面临的重大考验。在这种背景下，大众点评移动开发组必须要打造一个稳定、灵活、高效的运营配置平台。本文主要分享我们在建设高效的运营配置平台过程中积累的一些经验，以及面临的挑战和思考。
在日常开发中，老大经常要求我们给出一个完善并合理的技术方案之后才能进行开发。并且要求技术方案一定要细，要重点覆盖监控、异常处理、灰度、降级方案。同时要注重边界处理。最初，我的技术方案写的很粗，也没有理解老大说的边界处理到底是怎么一回事。于是乎，辛辛苦苦写了一周的方案，就会在技术方案评审的时候直接打回重做，甚至多次打回。 不过还好，在经历过几次大项目的方案设计后，我的方案设计越来越完善，直到最后老大非常认可并在组内进行参考。随着我的方案设计逐渐完善，也逐渐发现，不但编码效率越来越高，编码时思维更加清晰，而且方案中的每一个模块都贯穿了整个软件生命周期。
分库分表的文章网上非常多，但是大多内容比较零散，以讲解知识点为主，没有完整地说明一个大表的切分、新架构设计、上线的完整过程。
咸阳市大数据管理局是咸阳市政府下属机构，负责咸阳全市信息化建设、大数据管理和信息网络运行维护等工作。2019年，咸阳大数据管理局以Rainbond为基座，建设咸阳市的智慧社会操作系统，智慧社会操作系统的主要任务是连接资源、连接应用、连接数据、连接用户，2019年底已经完成智慧社会操作系统的主体建设工作。
转测试是项目上线前最后一道坎，需求全部做完并自测后，项目就进入了转测试阶段。很多没想到的问题都会在这个阶段涌现出来，这个阶段大家都会很辛苦，通常都会加班加点。为了缓解这个阶段的压力，我们需要做以下几个改进：
2020年一个全球永远难忘的年份。一场突然袭来的疫情，让一个劳动密集型的行业迎来了很多新的思考。原来一直以人为主的行业未来怎样通过智能客服在减少人工客服压力的情况下又提升客户体验？智能客服机器人是否就是未来的一个方向？在最近的两会，也有代表提出，智能客服不能搞成客服降级。一时间，客服机器人成为了大家热议的主角。 智能客服机器人在某种程度上确实能解决客服行业存在的痛点。在大家讨论上线客服机器人是升级还是降级的时候，不妨从以下几个维度思考一下。 我们真的需要机器人吗？ 我们可以让机器人做什么？ 为什么要上
大型的互联网产品总会有多台服务器支撑整个产品系统的运行，如果发布新版本代码的时候（比如我们公司还是最暴力的复制/粘贴，当然有自己的自动上线工具也不太可能避免这种问题），由于多台机器代码上线会有一定的延迟，造成的结果可能是机器代码版本不一致，导致处理请求造成不同的处理结果，引发脏数据问题，应该如何避免呢？ - 1，兼容，2，分步升级+导流控制； - 1，兼容，2，公告+暂停服务+自动化脚本； - 多环境的部署会导致数据差异，自动化的数据库部署脚本和上线演练很重要； - 新代码尽量保证兼容性，如果不能看业务是
SQL自动化上线的工作做了初步的设计，目标是希望对于业务同学使用是一个相对平滑的过程，把目前工单需求中的一些瓶颈点做到显著改进。
一款应用的开发大体流程如下： 1、项目立项：产品经理 2、需求确认：产品经理(业务逻辑说明文档) 3、业务确认：产品经理，技术经理，架构师 4、业务架构：技术经理，架构师（业务流程文档） 5、UI确认：产品经理，设计人员，开发人员全体 6、UI交互确认：产品经理，移动端，前段开发人员 7、接口确认：架构师，接口开发人员，移动端、前端开发人员 8.1、UI工时评估：产品经理，设计人员 8.2、接口工时评估：架构师，接口开发人员 8.3、移动端、前端工时评估：相关开发人员，技术经理 9、工时确认：产品经理，技术经理，设计人员 10、项目开发 11、测试用例及流程设计：产品经理、测试组 12、测试用例及流程确认：产品经理、开发人员，测试组 13、测试及debug：产品经理，测试组，开发 14、产品定版，release
SAP为独立实施的项目提供了面向过程的、清晰的、准确的实施路标。这个路标起到了项目向导的作用，用来确定步骤，明确转折点，并且通常用来设定整个项目的进度，使得可以使用最优的预算和资源，快速高质量的生成一个新的系统。ASAP路标包括下面几个阶段：项目准备，业务蓝图，实现，最后准备以及上线支持。 1、项目准备阶段 项目准备阶段主要是建立项目组织，包括项目团队、角色和职责。这一阶段确定系统实施的目标。还要确定项目的基本构造，包括硬件、网络要素。执行正式安装的规模和指标，并且初始化SAP系统。 1.1 定义项目目标和范围 SAP项目的任务和目标须与公司未来3-5年内的任务和目标一致。指导委员会的重要责任就是决定SAP项目的实施范围。SAP推荐使用“大爆炸”的方式，即公司一次性实施SAP大部分标准的功能和针对公司的特定行业解决方案。 只有通过“大爆炸”的方法才能使公司将SAP系统所获取的信息作为一项资源来使用，如人力、材料、资金，而不是把SAP当作是记录和报表系统。一个综合系统的真正优势只有在公司的所有实施点和办公业务都在SAP平台上运行时才能得到真正的体现。 1.2确定项目组织和资源 建立项目资源计划，项目资源需求包含以下几点： 在合适的阶段分配和支付财务预算； 获取并按照计划来配备相关的系统硬件、软件、网络系统； 选出业务骨干，这些人是他们所在部门的主要成员，并且被任命为功能团队成员，他们被赋予为系统进行全面调试和对最终用户进行培训的任务； 1.3 定义风险控制策略 SAP实施项目是一个标准软件包的实施，主要风险包括： 合适资源的缺乏； 在实施范围和系统功能的问题上缺乏清晰性，完备性和明确性； 需求获取和分析 理解SAP系统所提供的功能 功能上的差距评估和分析 正确配置和定制SAP系统 SAP系统的综合测试 数据风险，特别是各种主数据的准确性 通过制定有效的风险控制策略来控制上述可能的风险。 1.4准备项目计划 建立项目工作计划：项目经理制定项目的主工作计划，包括各阶段的完成时间点以及要提交的主要工作产品。 建立项目组培训计划：针对关键用户和最终用户的系统培训。 1.5项目启动 项目一般由一个发起会议来正式启动，参加这个会议的有管理人员、控制委员会成员、SAP顾问和小组成员。在项目启动大会上介绍项目的目标、项目组的组织成员及职责以及项目的主要工作计划。 1.6项目培训 模块顾问根据培训计划，执行项目组培训。 1.7开发、测试机系统准备 安装开发机、测试机系统，并给所有的项目组成员安装SAP桌面登录系统。 2、蓝图设计阶段 业务蓝图阶段主要处理需求的归档和最终的确定。小组成员和顾问在不同的业务活动领域内进行访谈，并召开项目讨论会，以获得各业务流程的确定需求。当前业务与未来业务的任何差别都必须进行识别，并要寻找和设计合适的解决方案。这个阶段最后输出企业蓝图文档，详细说明设计后的流程，包括公司结构和业务流程的文本和图形说明文件。一旦确定和验证了所有这些信息之后，蓝图就可以作为所有后续阶段的基础。 2.1 AS-IS业务流程调研 制定调研计划，确定调研的时间以及参加的人员，输出文档：调研计划； 设定调研提纲，根据访谈的人员的岗位，设定调研的内容，输出文档：调研问卷； 执行业务调研，根据调研计划，访谈岗位的人员，了解业务现状以及期望未来可达到的管理目标，输出文档：会议纪要； 完成业务调研文档，根据访谈的内容，整理形成公司AS-IS现状业务文档，输出文档：现状业务流程图，现状报告，包括如下内容： 现有系统的Landscape 组织架构 现状业务流程图 收集的现状报表、表单 业务主数据现状等； 2.2 TO-BE业务流程设计 根据现状业务以及未来管理的期望，组织跨模块讨论，编制TO-BE业务流程报告，然后对未来业务流程进行模块小组内讨论，然后提交指导委员会进行评审；输出文档：TO-BE业务蓝图文档。 未来业务流程文档包括如下内容： 确定未来系统的组织架构，比如设定公司代码、成本控制范围、利润中心、成本中心、工厂、仓库、销售组织、采购组织等组织架构。 编制业务流程文档，设定未来业务流程如何在部门间的流转，单据如何控制。 2.3开发需求确认 在讨论和编制业务蓝图的过程中，涉及到需要开发的业务需求，则需要确认各模块的开发需求，输出文档：开发计划。 2.4主数据的收集方案及计划 讨论确认需要收集什么样的主数据，以及主数据的收集内容及计划安排，输出文档，主数据收集模版、主数据收集计划。 2.5业务蓝图的汇报及签署 业务蓝图编制完成后，在模块内部进行
我特别反感那些不顾公司现状一上来就想要做研发效能度量的人，尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。
在erp软件的实施中,不是刚上就会有有成色起效，有高达50-60%左右失败的原因是出现在数据对接上，有的是数据准备不充分就仓促上线，有的是管理上的不顺畅，当问题出现时不知道是哪个环节出现了错误，而有的则是软件应用的操作人员未能及时更新而导致数据失真等等，而这些原因无不和数据挂钩。可见，在erp的实施中，数据有多重要。为了确保erp的实施成功，部署之前需要做那些准备呢？
ERP是一个庞大的信息管理系统，在ERP实施的各个阶段中，后期运维重要，它是整个ERP系统长期有效运行的有力保障。本文从ERP项目后期运维的地位、运维的不同阶段、运维的支持体系、运维过程中的知识体现以及运维所起的作用等方面对ERP项目后期运维进行全面研究。
说到系统稳定性，不知道大家会想起什么？我想大多数人会觉得这个词挺虚的，不知道系统稳定性指的是什么。一年前的我看到这个词，也是类似于这样的感受，大概只知道要消除单点、做好监控报警，但却并没有一个体系化的方法论。经过一段时间的摸索，我对系统稳定性有了较为体系化的认识，于是迫不及待地希望和大家一起分享。所以今天，就让我跟大家简单聊聊系统稳定性建设这个话题吧！
运维到底是干什么的？估计连运维工程师本身都不清楚，在百度上搜索也基本得不到答案，找了很多的运维老员工，终于总结出了运维工程师的工作内容：
背景 工作五年了，一直是做测试。认识了很多人大牛，也接触到很多新人，从他们身上看到了很多，自己的过去，自己的未来（当然很多是自己达不到的高度）。 做这测试这一行的，很多人都追求技术：自动化+性能，往往忽略测试流程，或者说是项目管理流程。 想法 流程是要结合团队来看的，换句话来说就是case by case，没有标准，适合团队/业务的流程就是好流程； Part1 待过做中国移动项目的传统行业，测试流程一套一套的，需求评审 -- 开发详细设计评审 -- 用例评审 -- 提测评审 -- 测试执行 -- 报告输出
TKE 集群 【新特性】上线 SecurityGroupPolicy 增强组件，支持为策略匹配的 Pod 绑定安全组，以控制 Pod 的出入站网络流量。 【新特性】对接 CAM OIDC IdP，支持业务 Pod 使用 Service Account Token 访问如 CVM、VPC 等云资源，同时确保身份验证的安全性。 TKE 原生节点 【新特性】上线 Pod 原地升降配能力，支持在不重启 Pod 的情况下直接修改 CPU、内存的 Request/limit 值，适用于流量突发、业务降本场景。 【新特
你的关注和转发是王豆豆的最大的赞赏，谢谢各位的支持。 昨天下午大神把组内几十号人召集在一起开Online bug分析大会，主要是针对近期线上事故从事故原因和解决方案两个维度来分析。 对金融软件来说，每一次的线上事故都有可能给公司带来重大的损失，少扣了用户的钱，为公司带来资金方面的亏损；多扣了用户的钱，则为带来不必要的合约或法律纠纷，故测试金融软件不比其他行业的软件，后者线上bug大多不会直接引起资金方面损失，最多就是用户体验不好，功能没有实现，导致用户量的流失。 对金融软件来说没有小bug，一旦出现bug那
3.测试计划，描述测试活动的规划、策略，运筹帷幄，防患于未然。里面重要的几个点，测试范围、测试策略、测试进度、准入准出标准、风险评估。测试范围，内部需要细化到模块，外部是否有依赖方或被依赖方，需要提前告知对方，安排联调。测试策略，人员的安排，每一阶段的测试活动，工具的使用、自动化、性能的介入。测试进度，需要固定的跟踪，如定期同步测试进度，告知风险。可提测的准入标准，测试后期是否符合上线条件的准出标准，业务人员的及时验收、反馈。风险评估，一般是时间规划不足，不能按时交付。
图灵平台是美团配送技术团队搭建的一站式算法平台，图灵平台中的在线服务框架——图灵OS主要聚焦于机器学习和深度学习在线服务模块，为模型和算法策略的线上部署和计算提供统一的平台化解决方案，能够有效提升算法迭代效率。本文将与大家探讨图灵OS在建设和实践中的思考和优化思路，希望能对大家有所帮助或者启发。
比漫长的上线流程更扎心的，是好不容易上线的功能，错过了最佳窗口期，结果没有达到想要的效果。
项目感觉要延期了，若是不延期，后期加班估计会非常多，若不调整项目质量可想而知，项目过程中暴露的问题太多，推动问题解决毫无进度，如前期需求不明确需要等、任务量大、时间短（上线时间固定），究其原因是项目流程上就有问题。
最近在整理人力资源管理系统项目上线的汇报材料，也顺便复盘总结一下工作经验，所以决定开笔记录下整个项目的上线和实施过程。人事系统的实施计划，在集团之前的IT战略规划中计划在今年启动，经过了前几个月的选型工作，最终，领导在三个系统之中选择了红海云的人力资源管理系统，其实这个都是大家意料之中的事，这个后面会说。
某天，项目经理、开发Leader、产品经理，突然找到你说，业务方非常着急，等着哪天要上线，并行的 3 个项目，都要在 这个月上线 。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
