devops

敏捷转型有很多坑，今天你跳了没有？ 1、敏捷和瀑布式只能二选一？× 1、敏捷开发和瀑布式开发是有结合的可能的，举一个例子，当有一个新的项目创意时，我们可以采用敏捷的方式快速试错，快速获得市场反馈，产出符合客户和市场需求的产品，但是如果后续的市场和需求比较稳定，我们完全可以回归的瀑布式开发的模式。 2、另一方面如果一个组织原有的模式是瀑布式开发，现在要转型为敏捷模式，那一定会有一个过渡期，这个转变的过程绝不是“一刀切”，会有很长一段时间采用混合模式！ 2、项目敏捷就够了（有项目就申请资源，结束了就回到资源池）；× 这是非常欠妥的做法，这种模式是希望做到项目敏捷，而不是组织敏捷，理想的认为项目采用敏捷管理方式即可，项目结束了就回到职能团队，所以每当有新的项目都要有一个磨合期，要重新确定项目角色，而职能组织并不能有效的给予支持，这样的结果是组织永远停留在原有的模式，项目敏捷也最终会变为伪敏捷。 3、TDD和ATDD是测试团队的实践；× 不管TDD还是ATDD都是团队整体的实践，TDD让测试与开发界限模糊，ATDD让需求与测试界限模糊；所以归根结底都是各个角色间合作的实践，而不是测试自己的变革； 4、价值驱动；× 价值驱动其实是没有错的，这正是敏捷提倡的交付原则，但是只有价值驱动吗，如果一切的情况只考虑价值，那就会带来很多问题，价值高的风险低，价值低的风险高，这样的情况一定是先做价值高的吗

当「小步快跑」的敏捷开发已成为国内互联网项目主流模式时，海外研发管理工具老牌军Jira集公有云版慢、私有部署贵、产品生态杂、长期维护成本高等弊端，无法良好满足本土需求，中国研发团队，亟需适应国内研发管理土壤的好产品。 深耕协同场景，聚焦 “ 效能 ” 7年的Worktile今日重磅上线企业级敏捷研发效能管理工具——PingCode，旨在帮助本土研发团队解决复杂的管理问题，降本增 效。 CEO王涛说： “ 数字化中国的未来，将诞生越来越多的软件公司和数字科技，PingCode将成为所有软件诞生过程的起点和基础设施，让每个伟大的团队生产伟大的产品，我们的职责是支撑这个开发的全过程，从Dev到Ops，让研发管理智能化、简单化、自动化。 ” PingCode，为效能而生 新平台PingCode的诞生，其背后是「十年蛰伏，一日破茧」的蓄力。 回顾过往，中国的协同SaaS领域群雄并起，彼时Worktile作为一款通用团队协作工具应用于泛行业场景，凭借产品力突出重围，成为赛道领头羊。 随着各行各业的数字化智能化演进，创始人王涛和李会军发现，在服务的几十万团队之中，有50%的协作企业覆盖研发管理场景，而“提升研发效能”恰恰是两人创立Worktile的初心。 2019年初，以多年协同工具研发经验为基石，Worktile团队开始迅速调整战略路径：保持原来的团队协作的同时，向研发管理领域开疆拓土。

自知水平有限，欢迎大家留言拍砖指正。 1、elasticsearch了解多少，说说你们公司es的集群架构，索引数据大小，分片有多少，以及一些调优手段 。 面试官：想了解应聘者之前公司接触的ES使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。 解答： 如实结合自己的实践场景回答即可。 比如：ES集群架构13个节点，索引根据通道不同共20+索引，根据日期，每日递增20+，索引：10分片，每日递增1亿+数据， 每个通道每天索引大小控制：150GB之内。 仅索引层面调优手段： 1.1、设计阶段调优 （1）根据业务增量需求，采取基于日期模板创建索引，通过roll over API滚动索引； （2）使用别名进行索引管理； （3）每天凌晨定时对索引做force_merge操作，以释放空间； （4）采取冷热分离机制，热数据存储到SSD，提高检索效率；冷数据定期进行shrink操作，以缩减存储； （5）采取curator进行索引的生命周期管理； （6）仅针对需要分词的字段，合理的设置分词器； （7）Mapping阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。…….. 1.2、写入调优 （1）写入前副本数设置为0； （2）写入前关闭refresh_interval设置为-1，禁用刷新机制； （3）写入过程中：采取bulk批量写入； （4）写入后恢复副本数和刷新间隔； （5

作为一名容器时代的程序员相信你已经或多或少接触过Docker，但同时你也会发现Docker虽然流行了多年，但之前却很少有公司直接将线上应用通过Docker容器进行大规模地部署。但最近三年，你会发现几乎绝大多数有条件的公司都已经在使用Kubernetes部署和发布自己的线上业务了。对一名普通开发人员来说，这一切可能发生得太快，以至于你还没有搞清楚它是怎么发生的，也会疑惑Docker和Kubernetes之间到底是个什么关系。 在今天的内容中，我们从Kubernetes的系统架构及容器编排核心概念两个方面来简单聊一聊这个问题，希望能帮助到你更好地理解Docker和Kubernetes之间因果关系。 Kubernetes介绍 在具体介绍Kubernetes之前不得不再提一下Docker，如果你用过Docker部署过程序，那么你一定会非常享受它带给你的丝滑体验，而联想到在此之前发布一个程序需要写各种脚本、进行各种环境匹配的糟糕体验，那么相信你的这种感觉会更加强烈。 而Docker之所以能做到这一点，就在于它以“Docker镜像”的方式一举解决了应用打包和发布这一困扰业界多年的技术难题，并且大大降低了普通开发人员运维部署应用的门槛。正是因为解决了应用打包这个根本性的问题，才使得Docker很快就被广大开发/运维人员所接受，迅速成为炙手可热的技术，并在一定时间内引领了容器化技术发展的浪潮。

10个微服务架构设计的最佳实践 微服务极大的改变了服务端引擎的架构方式。微服务不是一个单一的巨型的用来托管应用程序所有业务逻辑的代码库，而是反映了分布式系统模型，在该模型中，一组应用程序组件协同工作来满足业务需求。通过遵循十项基本的微服务最佳实践，你可以实现一个高效的微服务生态系统，从而避免不必要的架构复杂性。 微服务架构的收益 当从单体应用正确的迁移到微服务架构的时候，可以获得以下收益： 你可以根据自己的意愿选择一门语言开发微服务，按照自己的节奏独立发布它，并独立扩展。 组织中的不同团队可以独立的拥有自己特定的微服务，并且随着并行开发以及重用的增加，产品发布的时间会更快 。 可以更好的隔离故障，因为发生在特定微服务中的错误会在对应的服务中被处理掉，因此不会影响到生态系统中的其他服务。 但是，如果在构建微服务时未遵循正确的原则，则最终可能会陷入像纠缠在一起的意大利面一样的状态。 这让维护变得非常困难，因为这需要不同的团队一起协作来做变动，发布或者实现容错。 充分利用微服务是一门科学并且需要一些刻意练习。以下微服务最佳实践和设计原则将帮助你构建松散耦合，分布式和优化的微服务，以实现最佳价值。 10个微服务最佳实践 1.单一责任原则 就像代码中的类一样，它仅仅在单个原因情况下改变，微服务也是采用类似的方式建模。构建可能会改变一个以上的业务这种臃肿的服务是一个坏的实践。 2

Atlassian Team Tour 免费在线研讨会大中华地区企业专场终于来了！ 对于此次在 9 月 23 日晚 7 点整 举办的企业专场活动，我们重磅加码，大咖云集，您不但可以听到 Atlassian 首席营收官 Cameron Deatsch 对于企业变革的深度洞察（中文同传），Forrester Research 副总裁，研究总监 Michael Barnes 对于未来发展趋势的专业分析（中文字幕）。 我们还邀请到了中国金融行业大咖—— 汇丰科技基金服务软件负责人刘华，中国出口信用保险公司 DevOps 高级项目经理黄金泽，华泰证券敏捷转型负责人和敏捷教练孙健 与大家一起分享如何通过使用 Atlassian 实现企业敏捷转型。 点击 【这里】 立即报名 点击 【这里】 获取更多详情~ 来源： oschina 链接： https://my.oschina.net/u/4263597/blog/4559711