《启示录：打造用户喜爱的产品》读书笔记
好产品具备三个基本条件：价值、可用性、可行性，三者缺一不可。产品没有价值，开发团队再优秀也无济于事。 第一篇：人员现代软件产品团队成员 产品经理职责：评估产品机会；定义要开发的产品。 用户体验设计师交互设计师：负责深入理解目标用户，设计有价值的，可用的功能，以及用户导航和产品使用流程。视觉设计师：根据交互设计原型，制作美观的产品界面 项目管理人员产品经理完成产品定义后，开发团队开始开发产品。项目经理核心任务：制订计划和跟踪进度。 开发团队职责：负责产品的技术开发。 运维团队职责：互联网服务产品通常运行在服务器上，保证服务正常运行。 产品营销人员职责：负责对外发布信息、宣传产品，为扩展市场销售渠道、组织重点营销活动、促进产品销售提供支持 第二篇：流程11. 评估产品机会——确定待解决的问题只讨论待解决的问题，不应涉及具体解决方案。产品经理需要回答如下十个问题： 产品要解决什么问题？（产品价值） 为谁解决这个问题？（目标市场） 成功的机会有多大？（市场规模） 怎样判断产品成功与否？（度量指标或收益指标） 有哪些同类产品？（竞争格局） 为什么我们最适合做这个产品？（竞争优...
《持续交付发布可靠软件的系统方法》读书笔记
基础篇第一章：软件交付的问题第二章：配置管理第三章：持续集成第四章：测试策略的实现 部署流水线第五章：部署流水线解析第六章：构建与部署的脚本化第七章：提交阶段第八章：自动化验收测试第九章：非功能需求的测试第十章：应用程序的部署与发布 交付生态圈第十一章：基础设施与环境管理第十二章：数据管理第十三章：组件和依赖管理第十四章：版本控制进阶第十五章：持续交付管理
为啥新环境的Kafka性能这么差？
本故事纯属虚构，如有雷同，纯属巧合，一笑了之。公司分配给了A和B一个任务，测试容器化Kafka集群的性能。之前B在老机器上已经测试过一个版本，并写了完整的报告，算是有经验的老鸟了。现在到了一批新机器，需要在它们上面重新测试一下Kafka的性能，A主动承担这个该任务，要知道新机器不管从cpu核数还是内存大小都是老机器的两倍，而且新机器用的是SSD盘，而老机器用的是机械盘。A信心满满，认认真真地按照之前B写的文档操作。可测试结果让他大吃一惊，新机器的性能竟然不到老机器的一半。 网络问题？ A：这个Kafka集群压测数据怎么这么差？会不会是网络问题呢？B：之前我们用的是万M网卡，你这个是多少？A：网卡速度怎么看？B：用ethtool命令，后面加对应的网络接口名，看Speed值，就能知道是万M还是千M网卡了。 123456$ ethtool eth0Settings for em0:Supported ports: [ TP ]...Speed: 1000Mb/s... A：这是千M网卡，怪不得性能会这么差呢。B：你确定是网卡的问题吗？你压测的时候用nload命令查看一下网络的带宽有...
创建自签证书步骤
根证书创建 123$ openssl genrsa -out ca.key 2048$ openssl req -new -x509 -days 36500 -key ca.key -out ca.crt -subj "/C=CN/ST=shanxi/L=taiyuan/O=cn/OU=test/CN=example.com"$ #或者 openssl req -new -x509 -days 36500 -key ca.key -out ca.crt 手动输入配置 创建证书并使用根证书签发 123$ openssl genrsa -out app.key 2048$ openssl req -new -key app.key -out app.csr$ openssl x509 -req -in app.csr -CA ca.crt -CAkey ca.key -out app.crt -days 3650 -CAcreateserial 使用 Openssl 工具查看证书信息 123$ openssl x509 -in app.crt -no...
将字符串进行压缩后保存该如何做？
如何将zip文件挂载到容器Pod中呢？Prometheus operator中看到的一个特殊玩法。它将prometheus.yml进行压缩成.gz后再保存到secret中。可参考它来实现对数据的压缩与加密。具体的操作如下： 12$ echo "abc" | gzip | base64H4sIAAAAAAAAA0tMSuYCAE6BiEcEAAAA 解密操作： 1$ echo "H4sIAAAAAAAAA0tMSuYCAE6BiEcEAAAA" | base64 -d | gunzip 大家可以尝试下。另外需要注意的是，将该数据挂载到POD的文件中，文件是压缩后的gz文件。
性能测试方案设计与测试过程
性能测试过程 性能测试计划 按照模板生成性能测试计划 指标设计（并发数、在线数、TPS、请求超时）挑选典型交易（20%交易，覆盖80%流量）环境、数据准备（与生产环境尽量一致）场景设计（基础场景、专项场景）测试进度安排 需求分析、调研 了解业务需求 环境、数据准备： 系统部署 真实含义的业务数据 数据量为生产数据量三年以后的数据量。 场景分析设计 挑选交易，典型交易：高频交易，逻辑复杂的交易，集中时间段的场景 单交易运行——>单交易负载场景 混合场景设计：混合容量设计，浪涌设计（20->100,100->20） 稳定性场景设计（48小时、72小时持续压力验证） 场景执行、应用监控 执行测试场景 问题定位、分析优化 分析问题 回归验证 性能测试报告 测试结果汇总形成报告 性能测试方案扩展引入多样化的性能监控工具（prometheus/JVM/pinpoint/skywalking）丰富性能场景设计（扩展性场景、可靠性场景、网络异常等情况）可持续性能压测(Jmeter进行自动化...
持续交付发布可靠软件的系统方法（_交付生态圈）第十五章：持续交付管理
《持续交付发布可靠软件的系统方法》读书笔记 实现持续交付不仅仅是搭建一些工具，做一些自动化的工作，它依赖于交付过程中的每个人的协作。通过持续交付实践，可以快速且可靠地交付新版本。 配置与发布管理成熟模型 这个模型的最终目标： 缩短生产周期 减少缺陷 提高软件交付生命周期的可预测性 规范合规 有效发现和管理软件交付相关风险 交付更少缺陷的软件，降低成本 模型指导组织推进持续交付变革，使用戴明环，即计划——执行——检查——处理。 使用模型来分析所在部门的配置与发布管理模式 选择一个领域集中发力，该领域是你的薄弱环节，痛点所在 实施变革。先创建一个实施计划，选择真正感到痛苦的那部分人 一旦发生了变化，使用之前创建的验收条件来衡量这些变化是否达到了预期效果。组织所有相关人员召开回顾会议，找出改进点及潜在改进领域 重复上述步骤，积累知识，增量改进，推广到整个部门 项目生命周期团队的组建与磨合常常有以下五个阶段：创建期、风暴期、规范期、运转期、调整重组期。软件也有五个阶段：立项阶段、启动阶段、初始阶段、开发部署阶段、运维阶段。 立项阶段：业务分析、业务负责人及涉及部门有关人确立 启...
持续交付发布可靠软件的系统方法（交付生态圈）第十一章：基础设施和环境管理
《持续交付发布可靠软件的系统方法》读书笔记 基础设施与环境管理的目标是让所有测试环境（包括持续集成环境）都要与生产环境相似，特别是它们的管理方式。环境是指应用程序运行所需的所有资源和它们的配置信息。有如下这些属性：组成运行环境的服务器的硬件配置信息：如CPU类型和数量、内存大小、硬盘和网卡等；应用程序运行所需要的操作系统和中间件：如消息队列、应用服务器、web服务器及数据库服务器等的配置信息。基础设施代表了所在组织中的所有环境以及支持运行的所有服务，如DNS服务器、防火墙、路由器、版本控制库、存储、监控、邮件服务、日志服务等。准备部署环境及管理它，要基于以下原理，用一个整体方法来管理所有基础设施： 使用保存于版本控制库中的配置信息来指定基础设施所处的状态 基础设施应该具有自治特性，即它应该自动地将自己设定为所需状态 通过测试设备和监控手段，应该时时都能掌握基础设施的实时状况 基础设施还应该具有非常容易重新搭建的特性 为了减少在类生产环境中的部署风险，需要精心管理以下内容: 操作系统及其配置信息，包括各个环境 中间件软件栈及其配置信息，包括应用服务器、消息系统和数据库 基础设...
持续交付发布可靠软件的系统方法（交付生态圈）第十三章：组件和依赖管理
《持续交付发布可靠软件的系统方法》读书笔记 持续交付让应用程序处于随时可发布的状态。在大型重构或添加复杂功能时，要继续保持应用的可发布状态，需要对大型应用组件化。组件是指应用程序中的一个规模相当大的代码结构，它具有一套定义良好的API，而且可以被另一种实现方式代替。一个基于组件的软件系统，通常其代码库被分成多个相互分离的部分，每个部分通过有限的定义良好的接口提供一些服务与其他组件进行有限的交互。有人把组件称为模块。基于组件的设计是一种良好的架构，具有松耦合性。 保持应用程序可发布团队不断地增加新特性，可以给每次新特性创建新的分支，当新特性完成后，再将它合并到主分支。这将会导致合并周期变长，无法做到持续集成，这种方法不是最好的。提倡每个人都应该提交到主干。可是这样又该如何保证主干一直保持可发布状态呢？有如下四种策略： 将新功能隐藏起来，直到它完成为止。一种方法是把新功能直接放进主干，但对用户不可见，比如通过单独的URL来访问，通过Web服务器配置不允许访问其入口；另一种方法是通过配置项开关来管理。把功能半成品与系统其他部分一同发布是一个好实践。 将所有的变更都变成一系列的增量小修...
持续交付发布可靠软件的系统方法（交付生态圈）第十二章：数据管理
《持续交付发布可靠软件的系统方法》读书笔记 应用程序可以通过删除前一个版本，使用新版本替换旧版本的方式部署，但是大多数系统，数据无法使用这种方式进行变更，一旦某个系统发布到了生产环境中，关联的数据将不断增加。数据往往是系统中最有价值的部分。当我们需要对数据系统进行结构修改或者内容修改时，就需要相关的策略。对数据的修改是不可避免的，关键在于将数据迁移过程自动化。目前有一些工具对数据迁移提供了较多支持，它们还允许对数据库进行版本化管理。另一个重要部分是测试数据的管理。 数据库脚本化任何数据库的修改都应该通过自动化过程来管理。包括数据库的初始化，数据库所有的迁移都需要脚本化，并将脚本提交到版本控制库中。几乎所有的数据管理系统都支持通过自动化脚本进行数据存储的初始化工作。 清除原有的数据库 创建数据库结构、数据弯路实例以及模式等 向数据库加载数据 在大多数据项目中，数据库的使用要复杂得多。 增量式修改绝大多数据系统，对数据库更新时，要保留它们的数据。由于在部署时需要保留数据库中的已有数据，所以需要有回滚策略，以便部署失败时使用。这就需要对数据库进行版本控制。 在数据库中创建一个数据...