Service deliver

最新推荐文章于 2020-07-01 17:57:28 发布
最新推荐文章于 2020-07-01 17:57:28 发布
阅读量1.1k 收藏
点赞数
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/yww_poison/article/details/83007751
本文介绍了ITIL服务管理中的十大流程及服务台概念，并将其分为服务提供与服务支持两大类。服务提供包括服务等级管理、可用性管理等内容，而服务支持则涵盖服务台、事件管理等流程。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

转载: from http://industry.ccidnet.com/art/1550/20051123/378963_2.html

ITIL包括十大流程和一个服务台，十大流程又可以划分为两大类：一是基于战术层面的服务提供（Service deliver），包括服务等级管理、持续性、可用性、能力和财务管理；二是基于运营层面的服务支持（Service surpport），包括服务台、事件管理、问题管理、配置管理、变更管理、发布管理。

注:

现在的SAP，金蝶，用友之类的都是算做这个Service Delivery的吧

公司刚实施了SAP的HR系统，也是这个萨班斯法案的需求。

以前NI的Olite发布流程，倒也符合文中所说的流程。

yww_poison
关注
sms deliver解码
笔者从事电信媒体开发多年，愿意将多年的开发经验分享给同行
11-01 686
介绍SS7/M3UA承载的SMS Deliver消息承载的GSM短信解码
基于Service Worker实现WebRTC局域网大文件传输能力
WindRunnerMax
09-09 2078
是一种驻留在用户浏览器后台的脚本，能够拦截和处理网络请求，从而实现丰富的离线体验、缓存管理和网络效率优化。请求拦截是其关键功能之一，通过监听fetch事件，可以捕获所有向网络发出的请求，并有选择地处理这些请求，例如从缓存中读取响应，或者对请求进行修改和重定向，进而实现可靠的离线浏览和更快速的内容加载。
MQ与Webservice的区别
热门推荐
lulu147的专栏
04-20 1万+
Webservice 和MQ(MessageQueue)都是解决跨平台通信的常用手段，两者有哪些区别呢？ 个人认为最本质的区别在于 Webservice近乎实时通信，而MQ却通常是延时通信。 什么意思呢？ 因为webservice其实就是本地服务器程序调用远程服务器上的方法，属于两者之间的交互，请求的时候需要等被请求的服务器做出回应后，另一端才会有所动作，也就是说，如果你请求
fabric 2.0, orderer & peer, Deliver Service
Kingwel Blog
03-17 404
Deliver ServiceDeliver on OrdererHandlerPeerHandlerSame Deliver Handler Both orderer and peer support Deliver service. Deliver on Orderer In AB gRPC server, _AtomicBroadcast_Deliver_Handler supports D...
ITIL与ISO20000的关系
007 James Bond
12-19 1677
摘自豆丁网一篇文章   ITIL它不是一个服务管理标准，而更应该说是一种结构化的方法或流程框架。基于这种方法和框架，已经有越来越多的IT服务管理标准被开发出来了。在这些基于ITIL的IT服务管理标准中，最突出的要属英国标准BS15000-1:2002以及澳大利亚标准AS 8018.1-2004. 此外，还有一个南非版的BS15000标准。国际标准组织（ISO）已经接受了BS1500...
ITIL(v2) 系列学习1
IT新兵
06-22 1360
 前言在2007年ITILv3推出之后，ITIL这个概念从最佳Best practice实践变成最好Good practice实践。从此称呼的转变能够看出ITIL思想的普及化、平民化。ITIL v2已经使用了快20多年了，看看如今的ITIL的用户，成熟度依旧参差不齐。有的已开始琢磨着如何完善所有ITIL Support流程并开展实施ITIL Delivery中的各个流程；有的已经在开始
Hyperledger Fabric从源码分析事件机制（二）
pigff的博客
07-01 1078
上篇文章——Hyperledger Fabric从源码分析事件机制（一），我从 cmd 中添加--waitForEvent参数去监听事件这一入口出发，分析了DeliverClient这一侧的相关源代码，接下来这篇文章将会解析DeliverServer这一侧的相关源代码，准备好上车了兄弟们。 从proto文件中发现DeliverServer 事件相关的pb.go文件在protos/peer/events.pb.go中，关于DeliverServer的部分在576行： // DeliverServer is
The primary mental health project: A new way to conceptualize and deliver school mental health service
06-29
The primary mental health project: A new way to conceptualize and deliver school mental health service THE PRIMARY MENTAL HEALTH PROJECT: A NEW WAY TO CONCEPTUALIZE AND DELIVER SCHOOL MENTAL HEALTH...
Using AI to Deliver a Device as a Service
06-17
其中一个重要的应用领域就是设备即服务（Device as a Service, DaaS）。DaaS模式允许用户通过订阅的方式，获得硬件设备的使用权，而非一次性购买所有权。在这一模式下，设备的性能监控、管理及优化服务变得至关重要...
Secret Service Hidden Systems That Deliver Unforgettable Customer Service.pdf
11-11
根据提供的文件信息，本书《Secret Service Hidden Systems That Deliver Unforgettable Customer Service》由John R. DiJulius III撰写，主要探讨了如何通过隐藏的服务系统来提供令人难忘的客户服务体验。本书得到...
Hyperledger Fabric 排序节点处理 Deliver 请求的过程
yeasy的专栏
10-20 3762
Deliver，意味着客户端通过 gRPC 接口从 Ordering 服务获取数据（例如指定区块的数据）。 Orderer 节点收到请求消息，会首先交给 orderer.common.server 包中 server 结构体的 Deliver(srv ab.AtomicBroadcast_DeliverServer) error 方法处理。该方法进一步调用 orderer.common.
sqlserver临时表的删除方法
beautifulsarah的博客
12-28 3509
  if object_id('tempdb..#temp') is not null Begin     drop table #temp End 一个#号的临时表是事务级别的，就是说一个临时表只存在于一个事务里面。一个查询中的代码就是一个事务里面的（不包括拼接的sql语句） CREATE TABLE #temp  (     n
BroadcastReceiver最全实例——静态、动态、系统（监听短信、网络连接状态、SD卡、应用安装……）
可乐淘的专栏
04-11 2861
BroadcastReceiver 原理推荐看这篇博客：http://yangguangfu.iteye.com/blog/1063732 实例，请看本文。 AndroidManifest.xml <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.cctvjiata
ClearCase之删除Delivered Baseline的方法
自得其乐的崔秉正
07-18 3741
在ClearCase学习与使用过程中，有时会出现要删除一个Component的问题，但是这时会提示，有Baseline没有删除，仔细检查一下，发现是一些Deliver Baseline，这些Baseline不能直接用cleartool rmbl删除，而IBM Rational ClearCase Support中去搜索，会发现删除这种Baseline的方法只提供给购买了服务的用户，我只好自己尝试。
超级账本Fabric的架构与设计
博客
09-07 6566
超级账本Fabric项目自诞生之日起就吸引了全球众多企业的密切关注，已经先后发布了两个大的版本，0.6实验版本（2016年9月）和1.0正式版本（2017年7月）。 目前，超级账本Fabric架构上核心特性主要包括： 解耦了原子排序环节与其他复杂处理环节，消除了网络处理瓶颈，提高可扩展性； 解耦交易处理节点的逻辑角色为背书节点（Endorser）、确认节点（Committer），可以根据负载...
ClearCase Deliver过程解析
自得其乐的崔秉正
07-12 4746
 本文部分写作于2006年3月，当时主要的目的是明确Deliver步骤，了解如果写针对Deliver写Trigger脚本，最近下载了新的ClearCase 7.0文档，其中有了对Deliver的官方解释，在此做一个对比。我的理解原文：   如果要针对deliver_start这个创建Trigger，则要了解deliver这个clearcase操作具体步骤，以下是我对deliver这个clear
scheduleCrash报错：无法传递广播('can't deliver broadcast' failed)如何解决？
最新发布
06-17
<think>我们正在处理一个Android系统报错："scheduleCrashfor'can'tdeliverbroadcast'failed"，具体表现为无法传递广播，导致进程被终止（Crashingit）。根据引用[1]和[2]，该错误通常发生在广播传输过程中，可能由于广播数据量过大或接收进程无法及时处理广播。分析：1.引用[1]显示，BroadcastQueue无法将广播传递给com.baidu.launcher（进程ID为951），因此系统尝试终止该进程。2.引用[2]指出，这可能是由于广播传输的数据量过大，导致抛出RemoteServiceException。同时，该引用还质疑了sendBroadcast方法是否可能抛出RemoteServiceException。解决方案思路：1.检查广播发送的数据量：避免在Intent中传递过大的数据（如位图或大量数据），因为Intent传输有大小限制（通常为1MB左右，不同版本和厂商可能不同）。2.优化广播接收：确保广播接收器（BroadcastReceiver）能够快速处理广播，避免在主线程中进行耗时操作。3.使用其他进程间通信（IPC）方式：如果确实需要传递大量数据，考虑使用ContentProvider、文件共享或基于AIDL的Service等方式。4.检查广播接收器是否被阻塞：如果接收器所在进程的主线程被长时间阻塞，可能导致无法接收广播。确保主线程不被阻塞，耗时操作放在子线程中。具体步骤：步骤1：检查广播发送的数据量-定位发送广播的代码，检查通过Intent传递的数据大小。-如果数据过大，考虑使用其他方式传递，例如只传递一个标识符，然后通过其他方式（如数据库）获取数据。步骤2：优化广播接收器-确保在广播接收器的onReceive()方法中不要进行耗时操作（超过10秒可能导致ANR）。-如果需要执行耗时操作，应该启动一个Service来处理，而不是在接收器中直接处理。步骤3：使用替代的IPC方法-如果数据量很大，使用文件或者ContentProvider共享数据，然后通过广播传递一个指向该数据的URI。步骤4：检查目标进程状态-错误信息显示目标进程（com.baidu.launcher）被终止，可能是因为该进程已经处于不健康状态（如ANR、内存不足等）。需要确保目标进程能够及时处理广播。-如果目标进程是自己的应用，检查是否有内存泄漏、ANR等问题。步骤5：使用显式广播-确保广播是显式的（指定接收者的包名或类名），避免使用隐式广播（除非是系统广播），因为隐式广播在Android8.0（API26）以上被限制。步骤6：增加广播发送的Flags-尝试使用FLAG_RECEIVER_FOREGROUND，使广播优先传递给前台应用。-或者使用FLAG_RECEIVER_REGISTERED_ONLY，只发送给已注册的动态接收器（避免静态接收器延迟）。步骤7：避免在广播中传递自定义Parcelable对象-如果传递自定义Parcelable对象，要求发送端和接收端有完全相同的类（包括包名和类名），否则在反序列化时会出现异常。建议使用基本数据类型或系统支持的Parcelable类型。步骤8：检查系统日志-通过adblogcat获取更多日志，查看是否有相关异常（如TransactionTooLargeException）或其他线索。示例代码优化：假设原始发送广播的代码为：```javaIntentintent=newIntent("com.example.MY_ACTION");intent.putExtra("large_data",largeByteArray);//largeByteArray是一个大字节数组sendBroadcast(intent);```优化为使用文件传递：```java//将大数据写入文件Filefile=newFile(context.getFilesDir(),"temp_data");FileOutputStreamfos=newFileOutputStream(file);fos.write(largeByteArray);fos.close();//发送广播，传递文件路径（或URI）Intentintent=newIntent("com.example.MY_ACTION");intent.putExtra("data_file",file.getAbsolutePath());sendBroadcast(intent);```在接收端，读取该文件获取数据。注意事项：-文件读写要注意权限和同步问题。-及时删除临时文件。如果上述方法无法解决问题，可能需要深入分析具体场景。由于错误信息中提到“Crashingit”，可能是系统主动终止了接收进程，因此需要确保接收进程的稳定性。根据引用[2]中提到的，sendBroadcast方法本身不会抛出RemoteServiceException，这个异常可能是系统在传递广播过程中内部抛出的，所以我们应该从优化广播发送和接收入手。如果问题仍然存在，请提供更详细的日志和代码片段以便进一步分析。相关问题：1.如何避免在Android中因为广播数据量过大导致的问题？2.Android中进程间通信（IPC）的方式有哪些？各自适用场景是什么？3.如何优化广播接收器的性能以避免ANR？4.如何分析Android系统日志（logcat）来解决此类问题？</think>### 解决 "scheduleCrash for 'can't deliver broadcast' failed" 错误方案 该错误发生在 Android 系统无法向目标应用传递广播时，系统尝试终止目标进程但失败。以下是根本原因分析和解决方案： #### 核心原因分析 1. **广播数据过大** - 广播 Intent 携带数据超过 Binder 传输限制（通常 1MB） - 导致系统抛出 `TransactionTooLargeException` 变体错误[^2] 2. **目标进程异常状态** - 目标应用处于冻结/阻塞/崩溃状态（如 ANR） - 进程 PID 存在但无法响应广播（示例中的 com.baidu.launcher）[^1] 3. **广播超时机制** - 系统广播队列（BroadcastQueue）默认 10 秒超时 - 超时后触发 `scheduleCrash` 强制终止进程[^1] #### 解决方案 **1. 优化广播数据传输** ```java // 错误方式：传递大数据 Intent intent = new Intent("BIG_DATA_ACTION"); intent.putExtra("image_data", largeByteArray); // 可能超过 1MB // 正确替代方案： // 方案1：使用文件描述符传递 ParcelFileDescriptor pfd = ParcelFileDescriptor.open(file, MODE_READ_ONLY); intent.putExtra("data_fd", pfd); // 方案2：使用 ContentProvider intent.setData(Uri.parse("content://com.example.provider/data123")); ``` **2. 优化广播接收处理** ```java public class MyReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { // 避免主线程耗时操作 new Thread(() -> { // 异步处理复杂逻辑 processBroadcastData(intent); }).start(); } } ``` **3. 关键配置调整** - **AndroidManifest.xml 优化：** ```xml <receiver android:name=".MyReceiver" android:directBootAware="false" android:process=":broadcast_worker" <!-- 独立进程 --> android:exported="false"/> <!-- 最小化暴露 --> ``` - **发送端优化：** ```java // 添加 FLAG 避免后台延迟 intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND); // 控制接收范围 intent.setPackage("com.target.app.package"); ``` **4. 诊断工具** ```bash # 检查广播队列状态 adb shell dumpsys activity broadcasts # 监控 Binder 事务大小 adb shell dumpsys activity service all | grep "Binder transaction" ``` #### 预防措施 1. 广播数据遵循 `10-100KB` 最佳实践 2. 使用 `LocalBroadcastManager` 替代系统广播 3. 重要广播添加超时重发机制： ```java private void sendBroadcastWithRetry(Intent intent, int maxRetry) { new Handler().postDelayed(() -> { if (!isDelivered && retryCount < maxRetry) { sendBroadcast(intent); retryCount++; } }, 2000); // 2秒重试 } ``` > **关键提示**：当出现 `ProcessRecord.kill, reason = scheduleCrash` 日志时[^1]，表明系统已判定目标进程不可恢复，此时应优先检查目标进程的健康状态（内存泄漏/死锁等），而非广播发送逻辑。 ### 相关问题 1. Android 广播传输的数据大小限制具体是多少？不同版本有差异吗？ 2. 如何检测和定位 Android 应用中的 BroadcastReceiver 性能瓶颈？ 3. 除了广播，Android 还有哪些高效的跨进程通信方式？ 4. TransactionTooLargeException 在哪些场景下会发生？如何避免？ [^1]: BroadcastQueue 日志显示无法传递广播导致进程强制终止 [^2]: RemoteServiceException 分析表明大数据量传输是常见诱因
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值