58沈剑,互联网架构技术专家,“架构师之路”公众号作者。曾任百度高级工程师,58同城高级架构师,58同城技术委员会主席,58同城C2C技术部负责人。现任58到家技术委员会主席,高级技术总监,负责58速运研发与管理工作。本质,技术人一枚。
互联网研发团队,底层技术部门作为业务技术部门的支撑,如何处理上下游的管理,带好团队,是将要分享的内容:
1)底层技术部门要推一个工具,框架,组件,业务技术部门不支持,怎么办?
2)守土有责,禁止业务技术部门违规,却反遭投诉,怎么办?
3)系统正常无人过问,系统异常总背锅,怎么办?
4)N年总干一件事,没有业务成就感,怎么办?
5)技术氛围不强,士气比较低落,怎么办?
10年以上Oracle数据库技术支持、运维管理经验,支持过的数据库超1000套,长期为大型企业核心业务系统数据库提供方案设计、性能优化、故障处理、应急容灾、安装配置等技术服力。在15年的数据库项目管理实践过程中积累了丰富的实战经验,包括:全球最大的OLTP系统与OLAP系统数据库设计维护经验,16个RAC集群大规模数据库系统设计维护经验,500公里以上ACTIVE DATAGUARD数据库容灾系统规划实施经验,各种疑难杂症问题处理经验,各种平台版本数据库维护、优化经验等,在性能优化、规划设计、故障处理、安装配置等技术领域有自己独到的见解和处理经验。
裴丹博士是清华大学计算机系长聘副教授、特别研究员、青年千人。他目前的主要研究方向是AIOps。目前与多家大型互联网公司在AIOps领域都有合作。裴博士在美国UCLA获得了博士学位,之后加入美国AT&T研究院担任资深研究员、主任研究员。 裴博士在智能运维领域发表了100余篇学术论文和20多项美国专利授权。他是ACM和IEEE的Senior Member。
本次演讲将提出一个定量度量运维自动化程度和智能化程度的指标,即每个运维人力所能管理的计算资源数量。这个指标越高,运维的无人化程度就越高。要想从一人管理几十台服务器,逐渐提升为一人管理几百、几千、几万、几十万台机器,就必须逐渐引入AIOps算法模块,用自动决策代替人力决策,最终能用极少的人力自动处置软硬件故障、自动处置用户行为变化、自动处置变更。
现任甜橙金融信息技术部高级总监、运维技术中心负责人。具有多年数据库架构设计经验,设计并实施了甜橙金融云数据平台。
从开发到运维,伴随腾讯社交网络运营部成长的十年,负责过腾讯社交产品所有业务运维工作,目前主要负责业务运维、织云产品、AIOps体系等团队管理工作。 经历多个业务产品的诞生到蓬勃,伴随着运维团队的成长和成熟,见证着腾讯一代代运营技术的创新和发展。作为运维界老兵有好多故事想和大家讲,也有很多展望,特别愿意听听各位经历的酸甜苦辣。
运维领域技术创新这几年高速发展,手段越来越复杂,方向越来越多。特别是AI技术在运维技术上的运用,帮助运维技术和体系出现跃进式变化,如何判明方向和尝试创新?在建立基于AI的运维体系上少走弯路?以史为鉴。基于腾讯运维建设的真实历程,全面分析透视运维领域中自动化和监控体系的演进和技术迭代,AI实践与落地技巧,分享腾讯运维经验的同时帮助大家打开思路,共建创新运维,迎接AIOps
就职于汇丰16年;具有超过16年的软件开发经验,超过10年的项目和团队管理经验;具备丰富的大型项目管理和开发经验;是早期敏捷践行者,起步于极限编程,精通各种主流敏捷与DevOps方法、实践及工具;曾担任多个全球敏捷团队的技术主管和带领部门进行敏捷与DevOps转型;精通Java前后端开发及相关框架与技术;著有《猎豹行动:硝烟中的敏捷转型之旅》。
DevOps和敏捷教科书里很多的案例都是像互联网产品这样的面向消费者(To C)产品的。但是作为银行的软件开发部门,我们面对的情况则完全不一样,甚至有很多产品和服务是由供应商开发的。直接套用教课书的方法,势必踩出不少坑。我们需要深入理解业务部门的需要,找出更适合业务特点的方法。
具体内容包括:
● 难点:业务需要计划与承诺;攻克:项目计划依然重要
● 难点:业务组织架构复杂,难以找到PO,依赖供应商开发;攻克:通过敏捷实践和工具实现高效沟通与交付
● 难点:需求不清晰、复杂且难以理解;攻克:实例化需求确保正确交付和持续交付
小米智能云运维部DBA负责人。八年数据库相关产品运维及开发经验,曾就职于百度(资深DBA)、豌豆荚(DBA负责人)等互联网公司,目前负责小米智能云数据库架构优化及及团队建议。精通大规模数据库系统运维及架构优化。
讨论当前SQL评审及优化的痛点及难点,对比现有的开源SQL评审及优化产品,讲解小米开源的sqloptimizer工具及如何解决这些痛点的。涉及SQL改写的启发式算法、数据采样算法以及索引优化算法等。
阿里巴巴资深运维,11年加入阿里,先后从事多条业务线应用运维及运维平台设计和研发工作,连续六年保障业务线双11稳定,有丰富的运维经验。目前主攻方向为自动化容量弹性伸缩管理,即在保障服务稳定性前提下面向应用或集群容量实时按需弹性伸缩调整,自动决策和执行,降低运维风险和成本,同时加速空闲资源流动效率,提升整体集群资源利用率。
传统运维在应用容量管理上处境艰难,成本和效率难以两全,阿里也走过相同的困境。此次演讲将分享阿里在容量管控运维上转型之路,应用弹性容量托管平台引入数据挖掘、机器学习等方法,面向阿里集团BU应用做自动化容量伸缩管理,无服务器化设计思想,在压缩成本的同时,提升研发运维效率。此外,空闲资源宏观统筹,如不同计算类型任务错峰复用,规模优化成本结构,提高单位硬件产能。
本次分享将通过集团内部容量托管落地、混部资源分时复用等具体实践详细展开。
梁小平,十年的IT与互联网开发和架构经验,2012年加入京东,现任京东商城基础架构部资深架构师,目前主要负责京东商城调度与集群管理系统阿基米德(Archimedes)调度和混合部署研发落地工作。
1. 京东商城阿基米德系统介绍
2. 京东商城阿基米德大规模集群调度实践经验
3. 京东商城阿基米德调度仿真系统介绍
4. 京东商城大规模混合部署实践经验
George于2016年底创立了全球领先的DevOps平台JFrog的中国分公司。George 在国内的数据中心、服务器架构、移动应用运营,以及DevOps领域拥有超过8年的经验。
王涛作为SequoiaDB巨杉数据库的联合创始人,目前担任SequoiaDB的CTO与总架构师。在王涛先生的领导下,SequoiaDB的技术团队从零开始打造的分布式数据库,如今SequoiaDB目前已经拥有超过40家大型银行用户,以及近百家企业用户,并已经在多个银行核心系统投入生产,并于2017年入选国际技术分析机构Gartner的数据库年度报告。
分布式NewSQL数据库目前已经成为包括金融行业在内的众多行业未来数据库应用的一个主要方向。
罗辑思维首席DBA及MongoDB中文社区北京分会主席,曾任奇虎360数据库技术专家。近9年专职数据库从业经验,主要从事MySQL、MongoDB、自动化运维及私有云平台建设,专注于开源数据库MySQL、MongoDB等相关技术领域的学习与研究。
1. MongoDB主要特性介绍
2. MongoDB常见架构部署建议
3. MongoDB读写一致性问题处理
4. MongoDB最新认证模式的坑
5. MongoDB读写分离存在的问题
6. MongoDB常见通用优化模式
现任职光大银行科技部数据领域架构师,曾任职于IBM全球咨询服务部从事技术咨询工作,具有十余年数据领域研发及咨询经验。目前负责全行数据领域系统的日常架构管理、重点系统架构设计及内部研发等工作,对分布式数据库、Hadoop等基础架构研究有浓厚兴趣。
1、 图谱(Graph)技术的多个应用层次,可视化、图数据库、图算法。
2、 银行业应用图谱技术的典型场景。
3、 主流图数据库的架构分析及选型建议,JanusGraph(Titan)/Neo4j等。
4、 图数据库在光大银行的实践,系统架构设计案例。
PingCAP 核心工程师, TiDB-Operator 第一作者,目前主要负责 TiDB 与各种云平台整合,Rust 语言中文社区发起人,Kubernetes 资深工程师。
Kubernetes 从最初的无状态服务部署平台逐渐演化成云上标配“操作系统”,本次演讲将会分享如何在 Kubernetes 上管理有状态服务,如何借助 Kubernetes 实现数据库的自动化部署和运维,将 TiDB 打造成 Cloud-Native 数据库。
热爱开源事业, TCPCopy开源工具创始人之一,cetus(MySQL数据库中间件)项目目前负责人,目前在网易担任高级专家职位。爱好开源,关注分布式数据库、网络与机器学习。从事IT行业15年,具有丰富的架构实战经验和编程经验。
分享网易乐得开源的MySQL数据库中间件Cetus的整体架构以及在分布式事务、连接管理、路由策略、采用tcp stream/结果集压缩技术等诸多方面进行的性能优化。
携程技术保障中心资深运维AI工程师,毕业于复旦大学信号处理专业,硕士学位。负责携程多个AIOps项目的设计与研发,对人工智能、机器学习、神经网络及数学有浓厚的兴趣,对人工智能技术结合运维场景的实践有深入研究。
《Oracle DBA工作笔记》作者,竞技世界资深DBA,前搜狐畅游数据库专家,Oracle ACE,YEP成员,拥近十年的数据库开发和运维经验,目前专注于开源技术,运维自动化和性能调优。拥有Oracle 10g OCP、OCM、MySQL OCP认证,对shell,Java有一定的功底,现在每天仍在进行技术分享,每天通过微信,技术博客共享,已连续坚持1500多天。
1、MySQL现状和技术矩阵
2、MySQL开发规范
3、SQL优化
4、MySQL性能测试
5、MySQL高可用方案
6、MySQL架构方案