1. 问题说明在构建端云协同的 AI 辅助功能（如“AI脚本生成”、“智能问答”）时，鸿蒙手机端需要向云端大模型服务发起推理请求。测试发现，由于云端大模型推理耗时较长（通常在 15秒~60秒），在弱网环境或云端排队时，手机端经常抛出 Http Request Timeout 或 SocketTimeoutException 错误。用户界面长时间转圈后提示“网络异常”，但实际上云端任务可能正在执行或已完成，导致用户体验极差且资源浪费。2. 原因分析• 默认超时策略不适配： 鸿蒙原生网络库（@ohos.net.http）默认的读取超时（readTimeout）时间较短，适用于普通 API 接口，但不适用于生成式 AI 的长耗时场景。• 缺乏容错重试： 端侧在遇到网络抖动时直接抛出异常，未区分“业务失败”与“网络波动”，缺乏自动重试或状态保持机制。• 主线程阻塞风险： 若网络请求未正确处理异步逻辑，长时间等待极易阻塞 UI 线程，导致应用在等待 AI 结果时界面“假死”。3. 解决思路• 定制化网络配置： 针对 AI 业务场景，封装独立的网络请求实例，显式延长连接超时与读取超时时间，适配大模型推理时长。• 端云状态对齐： 采用异步 Promise 机制管理请求生命周期，确保在等待过程中 UI 保持响应（如显示进度条），并在捕获超时后进行有限次的自动重试。• 资源释放： 确保在请求结束或异常中断后，及时销毁 HTTP 请求对象，防止手机端内存泄漏。4. 解决方案利用 ArkTS 的 http 模块，构建针对长耗时任务的请求封装类，重点对 HttpRequestOptions 进行调优。代码示例 (ArkTS)：TypeScriptimport http from '@ohos.net.http';import { BusinessError } from '@ohos.base';// AI服务请求工具类export class AiNetworkService {    // 发起长耗时的AI推理请求  static async requestAiGeneration(prompt: string): Promise<string> {    let httpRequest = http.createHttp();        // 定制化配置：针对大模型场景延长超时时间    let options: http.HttpRequestOptions = {      method: http.RequestMethod.POST,      header: { 'Content-Type': 'application/json' },      extraData: {        "input": prompt,        "parameters": { "max_tokens": 1024 } // 模型参数      },      // 关键技术点：将读取超时设置为60秒，适应云端推理延迟      readTimeout: 60000,      // 连接超时设置为10秒      connectTimeout: 10000    };    try {      // 异步等待，不阻塞主线程      let response = await httpRequest.request('', options);            if (response.responseCode === 200) {        // 成功获取云端生成结果        const result = JSON.parse(response.result as string);        return result.data.content;      } else {        throw new Error(`服务端业务异常: ${response.responseCode}`);      }    } catch (err) {      let error = err as BusinessError;      console.error(`[AiService] 请求异常: ${error.message}`);      // 可在此处添加指数退避重试逻辑      throw error;    } finally {      // 必须销毁请求对象，释放端侧内存资源      httpRequest.destroy();    }  }}5. 总结• 关键技术难点： 解决了手机端与云端大模型进行长连接交互时的超时控制与连接稳定性问题。• 技术总结： 通过对鸿蒙原生网络接口 HttpRequestOptions 的精细化配置，实现了“端侧长等待、云侧长推理”的协同模式。• 效果总结： 优化后，AI 辅助功能的请求成功率在 4G/5G 弱网环境下提升了 40%，有效消除了因默认超时导致的“假失败”现象，保障了端云协同功能的可用性。

1. 问题说明在开发视频剪辑应用的“素材库”列表功能时，用户需要预览大量高清图片（4K/8K 分辨率）或高码率视频封面。测试发现，在鸿蒙低端机型（内存较小）上快速滑动列表时，应用界面出现严重掉帧（FPS 低于 30），并频繁发生应用闪退。通过 Profiler 性能分析工具查看，发现 Native Heap 内存持续飙升，存在明显的内存溢出（OOM）风险。2. 原因分析• 全量解码导致内存浪费： 列表页仅需展示缩略图（如 200x200 像素），但代码逻辑中默认加载原图进行解码。一张 4000x3000 的图片解码为 PixelMap 后需占用约 45MB 内存，加载 10 张即可耗尽手机可用内存。• 对象生命周期管理不当： ArkTS 的垃圾回收机制存在滞后性，快速滑动列表时产生的大量临时 PixelMap 对象未被及时释放，导致内存峰值叠加。3. 解决思路• 引入 ImageSource 降采样： 利用鸿蒙多媒体子系统的底层能力，在图片解码阶段直接进行“下采样（Downsampling）”。根据 UI 组件的实际物理尺寸计算缩放比例，只读取必要的像素信息。• 按需加载策略： 避免将整个图片文件读入缓冲区，而是通过文件描述符（FD）创建图像源，大幅降低 I/O 开销和内存占用。4. 解决方案使用 @ohos.multimedia.image 模块，通过计算原图尺寸与目标 UI 尺寸的比例，设置 DecodingOptions 中的 sampleSize 参数，实现高效加载。代码示例 (ArkTS)：TypeScriptimport image from '@ohos.multimedia.image';import fs from '@ohos.file.fs';export class ImageLoader {  // 加载并压缩图片，防止 OOM  static async loadThumbnail(filePath: string, targetWidth: number, targetHeight: number): Promise<image.PixelMap | null> {    let file: fs.File | null = null;    try {      // 1. 打开文件获取 FD，避免读取整个 Buffer      file = fs.openSync(filePath, fs.OpenMode.READ_ONLY);      const fd = file.fd;      // 2. 创建 ImageSource，此时不进行解码，几乎不占内存      const imageSource = image.createImageSource(fd);            // 3. 获取原图信息（宽、高）      const imageInfo = await imageSource.getImageInfo();      const rawWidth = imageInfo.size.width;      const rawHeight = imageInfo.size.height;      // 4. 计算采样率（sampleSize）      // 算法逻辑：若原图宽4000，目标宽200，则压缩倍数为20      let sampleSize = 1;      if (rawHeight > targetHeight || rawWidth > targetWidth) {        const heightRatio = Math.round(rawHeight / targetHeight);        const widthRatio = Math.round(rawWidth / targetWidth);        // 取较小的缩放比，确保图片能完整覆盖目标区域        sampleSize = (heightRatio < widthRatio) ? heightRatio : widthRatio;      }      // 5. 设置解码参数      const decodingOptions: image.DecodingOptions = {        sampleSize: sampleSize, // 核心优化点        editable: true,        desiredPixelFormat: image.PixelMapFormat.RGBA_8888,      };      // 6. 生成优化后的 PixelMap      const pixelMap = await imageSource.createPixelMap(decodingOptions);      return pixelMap;    } catch (error) {      console.error(`[ImageLoader] 图片加载异常: ${JSON.stringify(error)}`);      return null;    } finally {      if (file) {        fs.closeSync(file); // 及时关闭文件流      }    }  }}5. 总结• 关键技术难点： 解决了高清素材在手机端预览时的内存爆炸问题，平衡了画质与性能。• 技术总结： 深入应用了鸿蒙 ImageSource 的按需解码能力，通过动态计算 sampleSize，从源头减少了 90% 以上的无效内存占用。• 效果总结： 优化后，低端机型的列表滑动帧率稳定在 60fps，内存曲线由“持续攀升”转变为“平稳波动”，彻底消除了列表页的 OOM 闪退隐患。

问题说明开发可拖动悬浮球时,需要同时支持单击、双击、拖动三种手势,但会遇到严重冲突:核心问题: 拖动结束后松手,系统误判为点击,导致意外触发点击事件。实际场景: 应用市场中"宝宝学韩语"应用的萌宠悬浮球:单击播放韩语 → 拖动后误触发,体验极差双击跳转页面 → 被识别为两次单击拖动移动位置 → 与点击手势冲突用户痛点: 想移动悬浮球位置,松手瞬间萌宠就开始说话,完全不符合预期!2、原因分析2.1 手势识别的时序陷阱用户拖动悬浮球的完整过程是: 按下 → 移动 → 松开系统的识别流程:1. 按下并移动时,触发PanGesture拖动手势2. 松开时,PanGesture的onActionEnd执行3. 关键问题: 松开瞬间,系统继续检测其他手势4. 发现有TapGesture,误判为点击,触发onClick本质原因: 拖动的"松开"动作与点击的"按下松开"动作在系统层面无法区分。2.2 GestureMode三种模式的困境 HarmonyOS提供三种手势组合模式,但都无法完美解决问题:Sequence(顺序模式): 手势必须按顺序触发,无法同时支持点击和拖动。Parallel(并行模式): 所有手势同时生效,拖动结束后必然触发点击,这是最常见的错误选择。Exclusive(互斥模式): 只有一个手势生效,要么只能点击,要么只能拖动,功能不完整。2.3 为什么常规方案都失败开发者通常会尝试:直接用Parallel模式 → 拖动后误触发点击改用Exclusive模式 → 点击和拖动只能二选一分离手势单独绑定 → 优先级无法控制,问题依旧核心矛盾: 需要手势并行响应,但又要避免相互干扰,这是一个看似无解的矛盾。3、解决思路3.1 服务层架构设计三步解决法:第一步 - 状态标记: 用一个布尔变量`isDragging`记录是否正在拖动。第二步 - 延迟重置: 拖动结束后不立即重置状态,而是延迟100毫秒再重置。这个延迟时间是关键,既要避免误触发点击,又不能影响后续正常点击。第三步 - 条件判断: 所有点击事件执行前,先检查`isDragging`状态,如果正在拖动则忽略点击。3.2 时序控制完整的时序流程:用户按下并拖动 → isDragging = true (标记拖动状态)用户松开手指 → PanGesture.onActionEnd触发系统检测到松开 → TapGesture.onAction也被触发点击事件执行前 → 检查isDragging = true → 拒绝执行100ms后 → isDragging = false (延迟重置)用户再次点击 → isDragging = false → 正常执行为什么是100ms? 这是经过实测的最佳值:小于50ms: 点击事件已经触发,来不及拦截大于200ms: 用户拖动后立即点击会失效,体验不好100ms: 完美平衡点,用户无感知4、解决方案4.1 核心实现代码@Componentexport struct KoreanPetComponent {  @State positionX: number = 175;  @State positionY: number = -210;  // 关键: 拖动状态标记(使用private,不用@State)  private isDragging: boolean = false;  private startX: number = 0;  private startY: number = 0;  build() {    Column() {      Text('���')        .gesture(          GestureGroup(GestureMode.Parallel,            // 单击: 播放韩语            TapGesture({ count: 1 })              .onAction(() => {                if (!this.isDragging) {  // 检查状态                  this.onPetClick();                }              }),            // 双击: 跳转页面            TapGesture({ count: 2 })              .onAction(() => {                if (!this.isDragging) {  // 检查状态                  this.navigateToPetPage();                }              }),            // 拖动: 移动位置            PanGesture()              .onActionStart(() => {                this.isDragging = true;  // 标记拖动                this.startX = this.positionX;                this.startY = this.positionY;              })              .onActionUpdate((event: GestureEvent) => {                this.positionX = this.startX + event.offsetX;                this.positionY = this.startY + event.offsetY;              })              .onActionEnd(() => {                // 延迟重置,避免触发点击                setTimeout(() => {                  this.isDragging = false;                }, 100);              })          )        )    }    .position({ x: this.positionX, y: this.positionY })  }}4.2 三个关键技术点技术点1: 状态标记用private而非@State为什么`isDragging`不用@State装饰器?不需要触发UI重新渲染,只是内部逻辑判断避免状态同步延迟导致的判断失效性能更好,减少不必要的渲染技术点2: 100ms延迟重置的黄金时间为什么延迟时间选择100ms?太短(如50ms): 点击事件已经触发,拦截失败太长(如200ms): 拖动后立即点击会失效100ms: 既能拦截误触发,又不影响正常使用技术点3: 条件判断的执行顺序所有点击事件的标准写法:.onAction(() => {  if (!this.isDragging) {      // 第一步: 检查拖动状态    if (!this.isSpeaking) {    // 第二步: 检查业务状态      this.executeAction();    // 第三步: 执行业务逻辑    }  }})4.3 三个实用优化技巧优化1: 拖动距离阈值 - 避免手指轻微抖动被误判为拖动,设置5像素阈值,只有移动超过5px才算真正拖动。优化2: 边界限制 - 防止悬浮球被拖出屏幕外,使用Math.max和Math.min限制位置范围。优化3: 边缘吸附 - 拖动结束后自动吸附到屏幕左右边缘,避免遮挡屏幕中间内容,使用animateTo实现平滑动画效果。5、总结5.1 四个核心要点1. 使用Parallel模式 - 必须用并行模式才能让多个手势同时工作2. private状态标记 - isDragging用private而非@State,避免不必要的渲染3. 100ms延迟重置 - 拖动结束后延迟重置状态,这是解决冲突的关键4. 条件判断执行 - 所有点击事件前先检查isDragging状态5.2 实际效果在"宝宝学韩语"应用中应用此方案后:拖动后不再误触发点击单击双击准确识别手势响应流畅自然用户体验完美提升5.3 适用场景这个方案适用于所有需要同时支持点击和拖动的场景:悬浮球/悬浮窗组件可拖动的卡片和图标地图标记点游戏角色控制自定义拖拽排序列表5.4 关键注意事项延迟时间: 100ms是实测最佳值,可根据实际情况微调(范围80-150ms)。状态类型: isDragging必须用private,用@State会导致状态同步延迟。判断顺序: 先判断拖动状态,再判断业务状态,最后执行业务逻辑。资源清理: 组件销毁时记得清理setTimeout,避免内存泄漏。

codearts如何支持ios编译

【活动简介】本期活动以实践为主，将围绕CodeArts结合开发者空间和AI大模型的最新实践案例，以及Astro的最新实践案例，让更多开发者深入了解并体验CodeArts和Astro的强大功能与显著优势。活动报名>>入口<<【活动内容】一、资源准备——免费资源限时开通CodeArts Repo代码托管15元套餐DeepSeek Tokens 限时购创建CodeArts API示例项目免费开通CodeArts体验套餐Astro Zero 免费体验套餐免费领取200万Tokens，体验DeepSeek系列等模型免费领取开发者空间云主机二、课程学习——产品入门指导华为开发者空间快速入门DevOps实践与转型路径三、实践案例——动手体验应用快速构建>云主机+CodeArts实践开发初识云主机：CodeArts IDE入门基于云主机的CodeArts IDE运行Java电商项目基于云主机CodeArts IDE插件的代码质量检查基于CodeArts Repo云仓库管理云主机代码基于Repo和流水线门禁的分支合并与部署云端DevOps：实现持续交付生产线>>Astro+Deepseek实践开发华为云Astro轻应用智能语言助手校级就业指导轻应用接入DeepSeek智能分析>>>CodeArts+ModelArts+DeepSeek图生文体验在CodeArts API中探索AI识图作诗的魅力四、有奖互动完成实践体验：完成任一实践体验，并分享案例成果+体验心得/建议到>此活动帖<，将筛选优质分享内容，随机送出半入耳式耳机、案例学院卡、开发者徽章、体脂秤等奖品。完成问卷反馈：填写>>问卷<<，反馈产品建议和意见，即可参与抽奖（京东卡、移动电源、开发者徽章、案例学院卡等奖品） 

DevEco studioDev studio 有没有类似于Cline辅助开发插件？能让新手快速上手

近日，HCDG城市行上海站-DevOps专场技术实践沙龙活动圆满举办。活动特邀华为云DTSE、华为云技术专家以及观测云技术专家与开发者一起分享交流开发运维、持续集成、持续部署、可观测性等理念。各位专家与开发者一起展开动手实践活动，基于华为云CodeArts一站式开发平台实现开发全流程的体验。​活动开场，华为云上海DTSE介绍了DevOps的基本理念，不同的工具(Gitlab、Jira、Jenkins等)之间的差异，华为云CodeArts一站式开发生产线的基本能力，如需求管理、代码托管、代码检查、持续交付、持续发布、编译构建、部署、运维，以及制品仓库、测试、wiki文档等能力，将开发流程统一到一个应用中，即开即用，端到端打通开发流程，让开发者更专注于业务。▲ 华为云开发者联盟DTSE专家接着华为云高级技术讲师深入分享了华为X项目的DevOps实践，并基于CodeArts进行实操演示。他详细阐述了华为X项目DevOps全景图，包含需求、设计、开发者自测、集成测试、验收测试、发布、运维等流程，他详细讲解了各个流程涉及的活动、工具和标准。接着他以流水线为例，介绍了华为代码合入的流程，他指出，华为内部合入代码审核标准极高，需要代码检查、3人以上review、问题单、门禁等都通过。同时他指出，持续规划、持续集成、持续部署、持续测试，都是单模块能力的配置与使用，连续性、可视化、自动化程度低，华为云CodeArts实现了整个链条自动化，基于流水线完成CI/CD的最后一公里，实现端到端的DevOps流程，让流水线成为软件开发工具链中的一等公民。他通过实操演示，展示了华为云CodeArts工具链的使用方法，让现场开发者对华为云CodeArts产品的操作和DevOps理念有了更直观的认识。▲ 华为云高级技术讲师随后，观测云产品架构师刘锐为现场开发者带来了关于Java服务可观测性最佳实践的分享。首先刘锐老师指出分散式的监控系统面临的挑战，一体化监测平台是未来发展的必然趋势，同时介绍了观测云产品的核心优势。观测云产品构建了端到端全链路追踪分析平台、强大的用户体验感知平台，拥有超过 400+ 技术栈支持，包括数据采集、观测模板和监控配置，支持所有主流的编程语言和前端、客户端工程。接着刘锐老师演示了观测云产品在JAVA 服务可观测的案例，让现场开发者对如何提升服务可观测性有了深刻的理解。▲ 观测云产品架构师刘锐此次DevOps专场技术实践沙龙得到了现场开发者的热烈响应和高度评价。参会者纷纷表示，通过此次活动，他们对DevOps理念和华为云CodeArts软件开发平台有了更深入的了解，同时也收获了许多实用的技术和经验。华为云后续也将继续举办类似的技术沙龙活动，为开发者提供一个交流学习、共同进步的平台，为行业发展注入更多活力和动力HCDG（Huawei Cloud Developer Group 华为云开发者社区组织），是基于城市圈和技术圈，由开发者核心组自发开展的开放、创新、多元的社区技术交流组织。致力于帮助开发者学习提升、互动交流、挖掘合作，推动技术应用与本地产业结合、数智化转型和开发者文化发展。扫描下方二维码加入华为云HCDG▼▼▼

详细介绍一下 devopsDevOps是一种软件开发和IT运维的文化、实践和方法论的结合，旨在改进开发团队和运维团队之间的协作，以实现更快、更可靠的软件交付。DevOps的目标是通过自动化、共享和持续反馈来提高软件交付的速度、质量和效率。关键概念：协作 (Collaboration):DevOps强调开发和运维团队之间的协作，以减少隔阂和提高信息共享。团队应该共同负责整个软件交付过程。自动化 (Automation):自动化是DevOps的核心原则之一。通过自动化重复性的任务，如构建、部署、测试和监控，可以提高效率并降低错误。持续集成 (Continuous Integration - CI):CI是一种实践，开发人员将其代码频繁集成到共享存储库中，并通过自动化构建和测试流程来验证新代码的正确性。这有助于尽早发现和解决问题。持续交付 (Continuous Delivery - CD):CD建立在CI的基础上，旨在确保软件随时都是可交付的状态。开发团队可以通过自动化流程在任何时候将软件推送到生产环境。持续部署 (Continuous Deployment):持续部署将持续交付的概念推向极端，每次通过CI/CD流水线后，软件都会自动部署到生产环境，减少人工干预。监控和日志 (Monitoring and Logging):监控和日志是DevOps中不可或缺的一部分。通过实时监控和记录应用程序的运行状况，团队可以更快地发现和解决潜在问题。基础设施即代码 (Infrastructure as Code - IaC):IaC是通过代码来管理和配置基础设施的概念。它允许团队将基础设施定义为可维护的代码，并通过版本控制进行管理。为什么需要 devops，有哪些优缺点？DevOps（Development and Operations）是一种软件开发和运维领域的文化、实践和方法论，旨在通过促进开发团队和运维团队之间的协作和整合，实现快速、可靠的软件交付和运维。为什么需要 DevOps？加速软件交付：传统的软件开发模式中，开发和运维之间存在较大的沟通和协作障碍，导致软件交付周期较长。而 DevOps 强调自动化、持续集成和持续交付，可以大大加快软件交付的速度。提高软件质量：通过持续集成、持续部署和自动化测试等实践，DevOps 可以确保代码质量和系统稳定性，降低软件出错的风险，提高软件的质量。促进团队协作：DevOps 强调开发团队和运维团队之间的紧密合作和协作，打破了传统的“开发者 vs 运维者”的壁垒，实现了更加密切的团队协作和沟通。优化资源利用：DevOps 强调自动化和标准化，可以有效优化资源的利用，减少手工操作和重复劳动，提高团队的生产效率。快速响应变化：随着市场和用户需求的变化，软件需要快速迭代和更新。DevOps 可以帮助团队快速响应变化，及时发布新功能和修复 bug，保持软件的竞争力。DevOps 的优点：快速交付：DevOps 可以加速软件的交付周期，使得新功能和更新可以更快地上线。高质量软件：通过持续集成、自动化测试等实践，DevOps 可以提高软件的质量，降低出错的风险。团队协作：DevOps 促进了开发团队和运维团队之间的协作和沟通，提高了团队的整体效率和生产力。资源优化：通过自动化和标准化，DevOps 可以优化资源的利用，减少手工操作和浪费。快速响应变化：DevOps 可以帮助团队快速响应市场和用户需求的变化，保持软件的竞争力。DevOps 的缺点：学习曲线：实施 DevOps 需要团队成员具备一定的技术水平和工具使用经验，存在一定的学习曲线。文化变革：DevOps 需要对组织文化和团队协作模式进行改变，可能会遇到一些团队成员的抵触和阻力。复杂性：实施 DevOps 需要涉及多个方面的技术和实践，涉及到自动化、持续集成、持续交付等多个环节，具有一定的复杂性。工具选择：DevOps 涉及到多种工具和技术的选择和配置，需要根据具体的项目和团队需求进行选择，可能会存在一定的挑战。安全性风险：自动化和持续集成可能会增加一些安全风险，如代码漏洞、配置错误等，需要加强安全意识和控制措施。常见的流水线开源实现除了 jenkins，还有哪些？介绍一下除了 Jenkins 外，还有一些其他流水线开源实现工具，它们在自动化构建、测试和部署方面也有着广泛的应用。以下是几个常见的流水线开源实现工具：GitLab CI/CD：GitLab 是一个集成了代码仓库管理、项目管理和持续集成/持续部署功能的平台。其内置的 CI/CD 功能可以方便地创建和管理流水线，支持基于 GitLab 提供的版本控制功能进行构建、测试和部署。GitLab CI/CD 集成度高，与代码仓库紧密结合，提供了丰富的特性和灵活的配置选项。Travis CI：Travis CI 是一个托管式的持续集成服务，支持与 GitHub 和 Bitbucket 等代码托管平台集成。开发者可以在配置文件中定义构建、测试和部署任务，Travis CI 会自动根据提交记录或 Pull Request 触发流水线。Travis CI 简单易用，适合小型项目和个人开发者使用。CircleCI：CircleCI 是另一个托管式的持续集成服务，支持与 GitHub 和 Bitbucket 等代码托管平台集成。CircleCI 提供了可配置的流水线模板和丰富的插件支持，可以灵活地定制构建、测试和部署流程。CircleCI 还提供了分布式执行环境和缓存功能，可以加速构建过程。Apache Maven：Apache Maven 是一个用于 Java 项目的项目管理和构建工具，它内置了一些标准的构建生命周期和插件，支持自动化构建、测试和部署。Maven 的配置文件（pom.xml）可以定义项目的依赖关系、构建目标和部署配置，开发者可以通过 Maven 实现简单的流水线功能。Gradle：Gradle 是另一个用于 Java 项目的项目管理和构建工具，它基于 Groovy 和 Kotlin 编程语言，提供了灵活、高效的构建配置方式。Gradle 支持自动化构建、测试和部署，并且可以与持续集成平台集成，实现更加复杂的流水线功能。转载自https://www.cnblogs.com/houbbBlogs/p/18084087

有朋友提到职业发展放心的时候，涉及到 DevOps 和 SRE 话题。几年前我接触这两个概念，也会区分的不是那么明确，但也没人讲的很清楚。目前 DevOps 和 SRE 已经是大热的方向，但发现身边还是有人存在混淆情况，这里给出一些分享，来区分这两块。最常见的误区：DevOps 新概念，好高级哦SRE 是高级版 DevOps运维可以轻松转身 DevOps 工程师我们具体看看吧。一、DevOps 和 SRE 定义DevOps 是字面上 Dev 开发 / Ops 运维两者组合， 严格意义上 DevOps 如下（via DevOps - Wikipedia）：DevOps（Development 和 Operations 的组合词）是一种重视“软件开发人员（Dev） ”和“IT 运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。SRE 全称是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程实践中发扬光大。 他们还出了一本同名书籍「Site Reliability Engineering」， 让这个理念在互联网工程师圈子里广泛传播。Google 对 SRE 解释是（via Site Reliability Engineering - Wikipedia）：Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations whose goals are to create ultra-scalable and highly reliable software systems.我将其翻译翻译为中文：网站稳定性工程师是致力于打造「高扩展、高可用系统」，并将其贯彻为原则的软件工程师。从定义来看，DevOps 是文化、运动和惯例，而 SRE 是有严格任职要求的职位。 文化是软性定义，文化有更多概念可以捏造，而 SRE 定义精准，就少了想象空间（也可能 SRE 门槛高 ）。 按 Google 给出的说法是，SRE 工程师实践了 DevOps 文化。这个观点没错，但是国内的 DevOps 逐步独立出 DevOps 工程师， 所以在本文，我着重讨论的是 DevOps 工程师和 SRE 工程师两种职位对比。&lt;br/>二、两者的职能不同DevOps 文化，那么就没有一个具象职能要求。现在不少公司将 DevOps 职能单独抽取出来，称之为 DevOps 工程师。 那让我们看看 DevOps 工程师关心什么：DevOps 文化目的是提交交付速度， DevOps 工程师就自然会关心软件 / 服务的整个生命周期。一个简单的公式：速度 = 总量 / 时间，添上工程行业术语，即 交付速度 = （（功能特性 * 工程质量） / 交付时间） * 交付风险。功能特性交给产品经理和项目经理管理，DevOps 工程师需要关心剩下几个因素：工程质量 / 交付时间 / 交付风险。 DevOps 工程师职能如下：管理应用全生命周期（需求、设计、开发、QA、发布、运行）关注全流程效率提升，挖掘瓶颈点并将其解决自动化运维平台设计和研发工作（标准化、自动化、平台化）支持运维系统，包括 虚拟化技术、资源管理技术、监控技术、网络技术SRE 关键词是「高扩展性」「高可用性」。高扩展性是指当服务用户数量暴增时， 应用系统以及支撑其服务（服务器资源、网络系统、数据库资源）可以在不调整系统结构，不强化机器本身性能 ，仅仅增加实例数量方式进行扩容。高可用性是指，应用架构中任何环节出现不可用时，比如应用服务、网关、数据库 等系统挂掉，整个系统可以在可预见时间内恢复并重新提供服务。当然，既然是「高」可用， 那么这个时间一般期望在分钟级别。SRE 职能可以概括为以下：为 应用、中间件、基础设施等提供 选型、设计、开发、容量规划、调优、故障处理为业务系统提供基于可用性、可扩展性考虑决策，参与业务系统设计和实施定位、处理、管理故障，优化导致故障发生相关部件提高各部件资源利用率三、工作内容不同职责不同导致两个职位工作内容也不尽相同，我将 DevOps 工程师和 SRE 工程师职能列举如下：DevOps设定应用生命管理周期制度，扭转流程开发、管理 开发工程师 /QA 工程师使用 开发平台系统开发、管理 发布系统开发、选型、管理 监控、报警系统开发、管理 权限系统开发、选型、管理 CMBD管理变更管理故障SRE管理变更管理故障制定 SLA 服务标准开发、选型、管理 各类中间件开发、管理 分布式监控系统开发、管理 分布式追踪系统开发、管理 性能监控、探测系统（dtrace、火焰图）开发、选型、培训 性能调优工具很有趣的对比，DevOps 和 SRE 都会关心应用生命周期，特别是生命周期里面中变更和故障。 但是 DevOps 工作内容是主要为开发链路服务，一个 DevOps Team 通常会提供一串工具链， 这其中会包括：开发工具、版本管理工具、CI 持续交付工具、CD 持续发布工具、报警工具、故障处理。 而 SRE Team 则关注更为关注变更、故障、性能、容量相关问题，会涉及具体业务，产出工具链会有： 容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。四、DevOps 和 SRE 关系DevOps 首先是一种文化，后期逐渐独立成一个职位；SRE 一开始就明确是一个职位； 不少同学把 DevOps 和 SRE 搞混，是被两者表象锁迷惑，看上去这两者都有的工具属性、自动化要求也相似。 甚至有一些开发同学把这类运维工作都统一理解为：服务器 + 工具 + 自动化。这是盲人摸象，管中窥豹。从技能上来说，两者都需要较强的运维技能。 在职业发展天花板上，DevOps 可能缺乏 SRE 在一些专业领域的技能： 计算机体系结构能力；高吞吐高并发优化能力；可扩展系统设计能力；复杂系统设计能力；业务系统排查能力。 两者都需要软实力，但是 SRE 面临复杂度更高，挑战更大，要求也更高：分析问题、解决问题能力战胜困难决心面对挑战热情自驱学习DevOps 具有普遍意义，现代互联网公司都需要 DevOps，但是并非所有团队对高可用性、高扩展性存在需求，它们不需要 SRE。DevOps 工程师掌握相关技能之后，也有机会可以发展为 SRE 工程师。而一位合格 SRE 工程师，在有选择情况下面，我相信不会去转型为 DevOps 工程师。从专业背景来看，无论是 DevOps 还是 SRE 工程师，都需要研发背景，前者需要开发工具链，后者需要有较强架构设计经验。 如果有运维工程师想转型成为 DevOps 或者 SRE，那么需要补上相关技术知识。 毕竟，不是会搭建一套 Jenkins + Kubernetes 就可以自称为 DevOps / SRE 工程师。

这次进行的是CodeArts线上产品体验，那么CodeArts是什么呢？CodeArts是华为自研一站式软件开发生产线，软件开发全流程覆盖：支持需求管理、代码托管、流水线、代码检查、编译构建、部署、测试、制品仓库等全生命周期软件开发服务；开箱即用，云上开发。长话短说：这次体验了一把【Devops全流程体验-凤凰商城项目】根据官方文档的指导完成华为端到端（HE2E）DevOps实践：cid:link_0凤凰商城项目方案架构服务构成方案可以由5个独立开发、测试和部署的微服务组件组成：Web用户端服务器Web管理端服务器后台订单批处理程序订单缓存订单数据库项目结构  软件开发生产线：需求管理，代码托管，代码检查，编译构建，制品仓库，部署，测试计划，流水线  其它组件和服务：统一身份认证服务，容器镜像服务，弹性云服务器（或者云容器引擎）这些让我对 devops 有了一个初步的了解，对此也觉得这种开发方式很不错，非常符合实际的全流程环节：设计——开发——测试——部署。实操环节对于一个全流程开发来说，每个环节都有存在的必要~这里我就说说我在体验过程中的感觉。在进行代码开发的时候，修改和提交代码时在我输入 #之后，会出现一个可以滑动的选项栏来方便选定，但是我输入我需要的编号，里面却没有。在我直接复制编号之后，查看Task名称，在详情页中是可以看到状态自动变为“已解决”。是因为不包含 task 的搜索吗？     2. 在步骤八，配置流水线的情况编辑phoenix-workflow流水线的时候，也需要进行参数配置，我发现他原本的 dockerOrg 是不符合要求的，感觉可以在文档上添加一下说明。     3. 文档步骤八的结构                 其中 2 的描述是基于我们应用是部署在CCE上的，对于使用ESC弹性云服务器的人来说，对于这个可能会不理解。按照1到2的排列不合适，可以说明一下前提~    4. 这是第一次进行 devops 全流程的体验，和了解了整个过程，也是有所收获。对于我个人，整个开发流程来说，对流程的看法也不是很有见解。但是真的体验过程有点顺理成章的感觉

Q1：瀑布型研发团队怎么转型DevOps？A：首先，目前瀑布型研发模式、DevOps研发模式在业界是并存的，DevOps模式一般适合敏捷业务场景，需要更快更频的交付。因此要评估一下自己的软件研发是否需要转向DevOps模式。其次，提升软件交付能力主要从人员与组织、工程方法、最佳实践、工具平台、生态等方面去开展相关的工作。研发团队一定要掌握相关的方法、实践以及工具，才能更好地进行转型。Q2：企业中的普通开发人员怎么去推行DevOps落地？A：DevOps研发模式落地对于一个企业或者团队实际上是一个变革，建议公司或者至少部门管理者要大力支持。当然DevOps有一些实践（例如CI、CD等）还是可以在开发中进行推行落地的。Q3：对于DevOps的初学者 有什么好的建议？A：回归到提升软件交付能力主要从人员与组织、工程方法、最佳实践、工具平台、生态等方面着手。对于初学者，首先可以广泛阅读DevOps相关书籍（例如《DevOps实践指南》等），然后可以通过一个demo应用按照软件开发过程去使用DevOps平台（例如华为云DevCloud等），这些平台应该也会提供一定的学习材料。知行合一，一定要动手实践。Q4：敏捷开发和传统开发相比有什么不同？A：传统瀑布型开发一般是确定了需求与投资后，按照需求分析-开发-测试-部署-发布这样的阶段去开展的，各个阶段要有明确质量标准与检查点，按序执行，开展周期根据工作量来确定，理想情况下，发布意味着研发结束；敏捷开发一般是明确投入，需求大致准确，然后按照固定迭代（例如每2周）来确认优先交付哪些需求并进行开发交付，直至产品实现商业目标。Q5：实现持续有效规划应该先从哪个层面去入手呢？A：一般来讲，持续规划分2个层面，第一，产品商业计划书的开发、决策和持续的周期性审视过程。商业计划书主要阐述产品/解决方案定位、目标市场、竞争格局、路标、经营目标、业务策略等，可以年初制定，按季度评审，年末回顾。第二，需求层面持续开展的收集、分析、评审和优先级排序过程。持续进行产品Backlog和迭代Backlog的规划。Q6：敏捷和SDLC 有何不同？A：简单来讲，SDLC是软件开发生命周期管理，从理论上讲清楚了软件开发有哪些阶段。敏捷可以认为是面对商业敏捷时，进行软件开发的一种优秀方法与实践。Q7：公司在推进DevOps落地中如何快速打破壁垒，营造团队氛围，能够确定 “他们做什么” 和 “他们应该做什么以及为什么”A：DevOps落地是个系统工程，首先正如DevOps的CAMLS理念中指出的，文化Culture很重要，管理者有责任去塑造合作的意识与分为。其次DevOps落地并不是不需要体系流程了，公司需要建立适合自己的DevOps管理体系与流程，对于角色的职责还是要进行说明的，当然这并不是固定不变的。例如软件开发工程师在一定的条件下是可以开展测试、部署、甚至运维工作的。Q8：项目管理模式Scrum与Kanban的各自特点是什么？ A：Scrum和Kanban是目前较为流行的敏捷项目管理框架。简单来讲，Scrum在固定迭代Sprint来进行选好需求进行开发测试并发布版本，Kanban核心是一个可视化的工作流，工作任务持续在这个工作流上进行流动。详细的分析可以看两种框架的对比。当然业界也有提出了ScrumBan的敏捷项目管理框架。Q9：devops的适用范围是？ A：DevOps研发模式更适合TTM时间更多、发布周期更频繁、自运营的系统中。DevOps的相关实践（例如CI/CD)实际上在瀑布研发模型中也是可以适用的。Q10：敏捷开发相比于传统的瀑布开发模型，有什么优势？ A：目前瀑布型研发模式、DevOps研发模式在业界是并存的，DevOps模式一般适合敏捷业务场景，需要更快更频的交付。在各自适合场景下，两种模式各有优势。Q11：DevOps是否适用于小团队，作为个人开发者应该如何提升DevOps能力？ A：DevOps适合于各种规模的团队。回归到提升软件交付能力主要从人员与组织、工程方法、最佳实践、工具平台、生态等方面着手。对于个人开发者，首先可以广泛阅读DevOps相关书籍（例如《DevOps实践指南》等），然后可以通过一个demo应用按照软件开发过程去使用DevOps平台（例如华为云DevCloud等），这些平台应该也会提供一定的学习材料。知行合一，一定要动手实践。Q12：在DevCloud实践体验的时候，自动化编译部署那块一直无法通过，找不到相关的java包，希望能够跟进课程同步跟新A：如果在实践的过程中有问题，可以使用华为云工单系统，通过提工单的方式向华为云进行问题反馈，工程师会第一时间解答您的问题。在线提单：cid:link_0Q13：K8S 和 云原生有什么关系？ A：云原生是包括微服务、DevOps、容器化、持续交付等理念和方法，K8s只是一个集群管理的工具。Q14：SRE和DevOps有什么区别和联系？ A：DevOps通常由两种角色去发起，Dev和Ops，即开发和运维。SRE是Google首先提出的一个概念，Site Reliability Engineer（网站可靠性工程师），从Google运维体系出来的一个角色。SRE工程师会通过自动化工具帮助开发人员，以运维的角度去参与研发并提供一些支持，包括开发自动化部署及运维相关的工具，通过这些工具和流程使能开发人员。两者比较而言，DevOps概念和范围相对更大一些，SRE则聚焦在开发与运维层面。Q15：想要快速考取HCIP-Cloud Service DevOps Engineer的话，有什么建议？A：建议先看看考试大纲，熟悉要考哪些知识点，根据对应的知识点去逐步学习，华为云官网也有相应的免费培训课程可以进行学习，完成理论知识学习后结合实验手册在线实操，巩固知识点，还可以在线参加模拟测试，来进行不断地实践练习。详情参考：cid:link_1Q16：DevCloud 流水线怎么自动部署CCI集群？ A：目前DevCloud支持CCE集群，暂不支持部署CCI集群。Q17：Docker与虚拟机有什么不一样？A：从下图可以比较清楚的看到Docker和虚拟机的异同。左边的VM是虚拟机使用，Container是容器使用，也就是我们说的Docker。两边都有server端和Host OS（虚拟机上的系统）。我们知道每个APP上都有Bin/libs，在Docker容器技术环境下，相同的APP可以共用同一个Bin/libs，大大节省了所占的资源空间。Q18：K8s和Docker在应用上有什么区别？ A：Docker是一种容器技术，在实践中可以直接使用Docker进行镜像构建等操作；K8s是进行集群管理的技术手段，华为云DevCloud的帮助中心有一个凤凰商城的实践案例，和HCIP考试中的实验一样，只是多了CI/CD的环节，在这个环节中就使用了K8s。Q19：影响地图主要应用于哪个环节？ A：从HE2EDevOps实施框架图可以看到，在端到端的DevOps实践中，影响地图通常用于需求规划或业务规划阶段，与传统的Scrum流程相比，更偏业务侧。影响地图通过四层结构：why、who、how、what来拆解业务和需求，也可以用于运营或项目冷启动环节。Q20：应用场景以线上服务为主，一般会采用什么样的分支管理模式？ A：华为云团队也是应用场景以线上服务为主，采用特性分支的管理模式，同时会做多级流水线触发不同环境的流水线来做相关构建，除了开发环境的流水线以外，还有测试、类生产环境等流水线。

cci 集群已经创建，可以没看到获取 k8s config 的地方，如何跟 devCloud 的部署结合实现跟 cce 集群一样的自动部署呢

转发自:https://www.jiqizhixin.com/articles/2022-09-22-89月21日 ，国际权威分析师机构IDC发布《IDC MarketScape: 中国 DevOps 平台市场厂商评估，2022》报告。本次报告， IDC从公司规模、产品技术、市场份额以及未来发展战略等维度对众多云厂商进行评估，华为云软件开发生产线DevCloud在市场份额和发展战略两大维度均排名第一，再次位居领导者位置。华为云DevCloud作为一站式、安全可信、全流程敏捷的DevOps云平台，已上线13项端到端子服务，服务于220万开发者，应用于10多个行业，覆盖开发全场景，全面领跑DevOps云服务市场。报告指出，华为云DevCloud覆盖了软件交付生命周期环节，无缝集成各个服务产品，实现“需求—计划—代码—测试用例—软件包”等研发资产关联追溯，通过可视化、低代码、模板等降低门槛，提升效率，并提供用户研发场景自定义能力。基于深度学习模型等智能化方式，提供代码智能补全、强化故障智能分析预测与性能分析等能力。同时提供代码安全分析、安全代码仓、封闭构建、成分分析、移动应用安全等支撑全链路安全可信，防范供应链攻击，进一步增强 了DevOps 平台能力。一方面，华为对研发能力的持续投入为华为云 DevOps 提供了强大的技术优势，同时华为云 DevCloud 在研发团队、云原生架构、人工智能、开源社区等方面的投入，也为保持技术优势提供了保障。此外，华为云在几十个城市签订软件开发云创新中心协议，同时拥有上千家合作伙伴。同时，华为云通过线上线下技术支持、实践训练营、敏捷与 DevOps 咨询、培训与认证等服务，助力企业及开发者掌握工程方法、最佳实践以及工具链产品。通过为客户提供丰富的销售、技术支持、专业服务等资源，使能客户更好地进行研发能力变革与转型。IDC MarketScape: 中国 DevOps 平台市场厂商评估，2022据了解，作为行业领先者，华为云DevCloud已携手百万级开发者，在政府、物流、金融、教育、制造等10多个行业落地，助力企业构建了敏捷、高效、安全的数字化生产模式。使用华为云DevCloud，江苏财政构建了一体化财政业务系统，实现核心业务100%上云，业务上线从2个月缩短至1周，支撑10万用户、4万单位同时在线办理业务。德邦快递半年内，实现业务从线下到云上的转型，完成750多条业务流水线交付，上百个核心业务系统上云，同时代码问题下降71.74%。九牧卫浴售后系统100%实现自动化流水线作业，业务上线由数月缩短至1周，有效管控ISV开发过程及质量，大幅提升了售后服务效率。同时，华为云也积极推动软件开发生态发展，以最高等级会员身份加入CDF，成为Apache顶级项目 ServiceComb的主导者与核心贡献者；作为全国信息技术标准委员会软件与系统工程分委会副组长单位，参与多项开发运维能力成熟度模型国家标准的编制；提供开放的API，支持第三方平台集成，兼容开源社区的工具和平台，并打造了面向开发者的“沃土云创计划”，构建开放的开发者生态。转发自:https://www.jiqizhixin.com/articles/2022-09-22-8

DevOps 是目前最流行的开发模式，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测 试、发布更加快捷、频繁和可靠。而DevCloud (华为云 DevCloud) 是基于华为研发云的成功实践经验，通过云服务的方式提供 一站式云端 DevOps 平台。开发团队基于云服务的模式按需使用，在云端进行项目管理、配置管理、代码检查、编译、构建、测试、部署、发布等。因此我们对于DevCloud的学习是必要的.经过这几天训练营的学习与实践,我将自己的一些学习心得进行分享.我们为什么选择DevCloud? DevCloud提供一站式云端DevOps平台，能够管理软件开发全过程，解决了需求变动频繁、开发测试环境复杂、多版本分支维护困难、无法有效监控进度和质量等研发痛点。 DevCloud实现了软件研发过程的的可视、可控、可度量，让研发能力提升有章可循。 管理看板功能让公司软件研发能力可视化，有助于研发能力短板浮出水面；同时支持跨地域协作，客户可以参与开发，让反馈更快速、迭代更便利。 流水线功能能够可视化编排，提供一键式构建、部署；提交代码后可自动触发流水线，让软件上线提速一倍。 

在这段时间的训练营的学习过程中充分感受到华为云以及后台工作人员对开发者的友好,因为需要开通基础版DevCloud产品是需要花钱的,但是为了让我们更好的体验华为云给了我们代金券,所以大家不用担心需要花钱的事情,端正态度好好体验即可.通过对飞机大战游戏上云实验的体验,在实践方面我感觉自己掌握的还可以,但是在理论方面有所欠缺,所以我在体验结束以后恶补了一下相关的理论知识.我将我说学到的东西向大家分享,我们一起学习.编译构建:一站式持续集成,快速灵活地构建软件包 编译构建服务支持10+种构建标准、20+种框架，提供20+原子步骤，快速灵活配置构建任务。 部署:一键自动化部署应用到各类环境，提升部署效率 部署服务支持部署应用到物理机、虚拟机、容器等多种环境，通过配置不同的部署参数、部署方法,可将同一应用部署到不同的环境。 发布:提供全面的软件制品管理,保障CI/CD全流程的实现 发布服务是持续集成和持续交付的中间环节，存储软件开发过程中的中间产物，并为部署实施提供软件包来源、为构建任务提供私有依赖。