必须保持燃烧着的火。
V.O. Pelevin，“ Generation P”
哈Ha！ 我叫Alexander Soloviev，我是Miran数据中心的技术支持主管。
告诉我，您是否尝试过编写教科书？ 我不知道 尽管如此，以下文本是用于组织技术支持的一种培训手册。 作为文章的一部分，我想告诉您Miran数据中心的技术支持是什么：什么类型的“齿轮”旋转以及为什么它们以这种方式旋转，而不是其他方式。
为了方便读者，我将本文分为几个语义部分。
- 在第一篇中，我们将讨论TP工作的基本要素-人员配备，应用程序生命周期，优先级。
- 在第二部分中，我们将解决将技术支持工程师的知识保持在给定级别的问题。
- 在第三部分（最后一部分）中，我们将讨论如何使以上所有工作有效。
我将讨论动机，尤其是非财务动机，并提供一些有关组织公司奖惩的技巧。
技术支持基础
要组织技术支持工作，您需要回答一些简单的问题：
- 它需要对一种产品（服务）的支持，或者是关于多产品支持的，即 支持几种完全不同的产品？
- 技术支持电话需要什么SLA？
- 需要全天候支持吗？
首先
单产品支持需要最少数量的专家。 例如，如果您希望每个班次约有10个应用程序，则可以尝试将支持转移给专业工程师。
多产品支持需要选择产品专家，或者按复杂性区分呼叫流量，这在多个支持热线的组织中得到了体现。
我们采取了根据工程师的知识和能力将其分为三个部分的方法：第一，附加和第二技术支持热线。
第二个
SLA越严格，公司需要遵循的资源就越多。 这些资源非常丰富：合格的工程师，信息系统，设备，法规文件等。 考虑人员问题。 为了满足SLA的要求，工作人员应与平均时间的技术支持电话人数成比例，并考虑到时间和质量标准。
基于以上所述，我们的工程师队伍如下：
•第一线-10人；
•附加线路-4人；
•第二行-5人。
第三名
全天候的技术支持是一项昂贵的服务。 此服务在24x7x365模式下的高质量性能将至少需要5名工程师，这是最简单的情况，即 如果是单一产品支持。 如果您需要全天候组织支持，请随意将成本乘以5。但是，首先，请考虑是否需要它（可以在没有自助服务门户的情况下进行操作等）。 如果您仍然需要它，可以外包它。
这些人都在做什么
一线工程师的任务是快速有效地处理客户的申诉。 处理意味着正确分类并发送到工作。
经过处理后，第一行的工程师可以自行解决该应用程序，如果它是从“在此处，现在快速执行”部分中完成的，或者如果该应用程序是“长期播放”或“故障”，则将其转移到另一行。
额外的生产线工程师的任务是处理需要花费超过一天时间的应用程序。
二线工程师的任务是尽快进行故障排除并“在此刻”解决复杂的应用程序。
工程师模式
第一行 ：时间表-2/2，从08:00和20:00轮班12小时。
附加路线 ：时间表-五天，从08:00和12:00从8小时轮班。
第二行 ：时间表-2/2，从08:00和20:00轮班12小时。
工程师的班次时间表通过Google日历维护。
TP中的生命周期和应用程序状态
跟踪应用程序生命周期的最简单方法是根据以下方案：
我将分别解释每个要点。
- 新状态由从外部来源接收到的任何应用程序获取。 第一线工程师的任务是首先处理收到的申请，然后将其转移给承包商。
- 当专家忙于决策时， 打开状态将分配给应用程序。
- 如果该应用程序已被识别为垃圾邮件，则它将获取“ 已删除 ”状态。
- 如果该申请不是垃圾邮件，但对技术支持没有实质性吸引力，则将其分配为拒绝状态。
- 解决问题后，将根据执行者将已解决状态分配给应用程序。
- 状态停止是指应客户的提议或与客户达成协议而暂时中止了该应用程序的工作。
- 在客户认为自己的任务已成功解决之后，分配关闭状态。
应用程式输入
应用程序类型是最重要的标准。 它确定反应速度和解决故障单中指示的问题的时间。 根据ITIL，在Miran中，请求分为以下几种类型。 我按重要性顺序排列：
突发事件事件包括设备故障和故障，以及任何其他导致服务质量显着下降的事件。 此类应用程序按优先级顺序执行，并且优先于其他类型的应用程序。 只有事件可以优先于处理。
事件示例：服务不可用，硬件故障。RFS-服务请求客户对服务的需求是所提供服务的一部分。 该请求与IT基础架构中的故障无关。 在没有优先级应用程序的情况下，它将在常规队列中立即执行。
示例：重新启动服务器的请求。RFC-变更请求要求更改提供给客户的服务的组成和/或范围。 处理时间由公司管理层与客户协商确定。
示例：交换设备的请求。RFI-信息咨询请求提供有关服务的信息，包括能耗量报告，服务报告等。 在没有优先级应用程序的情况下，它将在常规队列中立即执行。
考虑到许多内部规则和命令，将根据从客户端收到的信息来计算影响响应和决策速度的应用程序优先级。 有两个优先级：初始和最终。 根据客户端设置初始优先级，并确定事件处理的速度。 最终优先级由工程师在工作完成后确定，并反映出服务质量下降的实际水平。 这些优先级通常不相等。
优先级分配如下：
- 网段的功能中断（通信中心不可用，基本交换机故障）-40；
- 提供给客户的几种服务的质量大大降低-30;
- 提供给客户的服务之一的严重降级-20;
- 服务质量下降，对其性质没有重大影响-10；
- 对客户服务无影响-0。
我认为这可以顺利完成理论分析。 在幕后，将有时间来响应事件和请求，升级级别，财务动机和其他信息，这或多或少是其他公司的标准。 让我们继续进行一些更有趣的事情。
保持所需的知识水平
在技术支持服务的工作中，我们努力规范所有受监管的事物，以使客户透明，并正式化和数字化可能在将来有用和适用的任何信息。 来自客户的反馈，员工的知识水平，他们的成就和成就-所有这些都经过精心数字化，分析，并随后影响管理决策。
在几天的休假后，技术支持工程师可能会更改一些法规，新的“介绍性”法规将会出现，这意味着在轮班开始时，您需要小心检查工程师知识的相关性。 这是在情境建模技术的帮助下完成的，方法是通过培训来解决需要特定知识的情境。 我们称一种情况为例。 在轮班开始时，工程师会收到一些用例的一部分。 这种方法允许工程师在他们的思想中保持必要的知识并不断更新它们。 结果，工作质量提高了。 为了减轻压力，解决用户案例的截止日期定在轮班结束时，尽管实际上对于专家来说这足够十分钟。
典型的用例到底由什么组成？
共有4个语义块：
- 信息块
它包含需要学习的有用信息。 - 块捆绑
该块使您可以将新信息与该信息在人类记忆中的“运输”相关联。 - 答案选项
实际上，这是内存中信息的“传输”。 - 证明链接
指向可信赖来源的链接，您可以在其中学习此信息。
这就是标准用户案例在历史资料示例中的样子用例的所有块在含义和主题上都相关。 理想情况下，信息块应包含一个提示选项的提示，为澄清起见，您需要打开校对链接并在此处详细研究正在研究的问题。
在介绍这种做法时，我遇到了一个不愉快的时刻：市场上没有一个成熟的工具可以让您存储知识库，“聪明地”分发员工的用例并检查他们的答案。
当前，我们正在使用许多工具。
- 请求跟踪器（RT） -定义系统交互的逻辑。
- 通过API的Google日历 “赠送”了员工列表以及每个员工的用例数量。
- Google Spreadsheets提供了有关形成用户案例的信息。
实际上，该系统的工作方式如下：
- 形成了参与知识培训的员工列表。
- 为每位员工定义了用例主题。
- 为每个主题创建一个用例，并将其转移给员工。
- 在工作日内，工程师必须解决所有用户情况。
- 检查答案，并将每个用例的验证结果存储在系统中。
一个好的工程师可以在大约一分钟内解决一个用户案例。 为了作弊和“计数”是很成问题的，我们照顾了自己的反作弊系统。
切记：在任何无法控制动力的部门中，切勿尝试管理员工的知识水平。枪，鹦鹉和动机
我足够详细地讨论了技术支持服务的工作方式。 仍然需要理解另一个重要点：为什么它甚至起作用？ :)
一切都取决于两个支柱。 这些支柱是非财务和财务动机。
著名的黑帮老大卡彭（Al Capone）说：“用一个好话和一把枪，您可以获得的不仅仅是一个好话。” 遗憾的是，在这个比喻中，金融动机是个好词，而非金融业已经是“老牌”了。
非财务动机
非财务动机的三大支柱：评估的饥饿，寒冷与和平的客观性，应计费用的证明，易于管理任何人对以现金表示的罚款都会有非常消极的反应……但是幸运的是，他们更容易担心“鹦鹉”的罚款。 同时，如果可以煮鹦鹉，鹦鹉会极大地激励员工。
我们选择了质量。
鹦鹉不在了 ，但是理论上您可以选择其他东西。 闲暇之所以是美好的，是因为我们全体员工都感觉到它，它的预期目的是对它的需求，因此无需向下属解释它的意义和意义。 首先，在选择一个会计单位时，应该从一个事实出发，即它不应该是“真空中的球形马”。 会计单位必须对员工有形。
在非财务激励的框架中，员工被剥夺的不是金钱，而是时间，因此也有机会利用非财务激励的收益。 这是不愉快的，但不像是罚款：这是增长的动力，而且个人对公司的忠诚度也不会受到损害。 休息会鼓励“壮举”。 员工可以将休息日用于其预期的目的：例如，在家休息，但这并不是很有趣。 更有趣的是
，去一家有二十一点和小姐的赌场花点时间，休假一些对自己或贵公司来说很重要的活动，例如：VHI以外的医疗服务，最终获得专业证书，健身或旅游套餐。
与金钱相比，唯一可以减少的时间是，每个用例（无论是直接使用还是金钱使用）都需要由主管部门进行单独验证，这并不总是很方便。 从我们这里出发的时间价格是3000卢布，您可能或多或少。 最主要的是通过使用非财务动机来给彼此带来安慰。
让我给您一个生动的例子，说明以非财务方式授予特定作品的情况。
用用户案例为知识库编写好的文档并不是一个过程，而是一个过程。 每个月都会有新事物出现：客户，设备，软件。 由于上述原因，所有这些都需要仔细注意和记录。
如果从一开始我就自己编写这些文档，那么现在知识库的补充系统几乎可以自动工作。 我的任务是引导员工朝正确的方向发展，给他们运动矢量并执行出口控制。
我的经验表明，配备足够数量用户案例的一份好的文档的“价格”为三天假。
工程师可以休假两天，因为他们不需要进行重大更正。
如果需要多次更正，一个人可以放一天假，而自己做一个比解释正确的做法要容易得多。
我们尝试腾出更多时间进行这项工作-从10天或更长时间开始。 但是实践表明，太多的奖励会吓跑，几乎没有人愿意接受它。 因此，重要的是不要过度提升员工。 它可以使您以最出乎意料的方式侧身。 做实验，但要小心。
财务动机
TP工程师完成的每个应用程序都将获得奖励。 奖金的价值与申请的复杂程度及其实施所需的资格直接成正比。 工程师的最终工资由这些奖金的总和决定。 当然，如果应用程序“歪曲”地完成了，那么它的好处就会耗尽。
另一个细微差别：工程师的薪水始终在其职位所决定的范围内。 在最懒惰的月份中，一个人的收入将不会低于此范围的下限，也不会在最高生产力的人中获得的收入超过上限。 但是，没有人会冒犯：所有门槛都受到惩罚，并且通过非财务动机鼓励加工。
总结一下
文章出乎意料地庞大，但这不足为奇：我们几乎完全检查了Miran技术支持的生命，只忽略了最无聊或最一般的细节。 但是，如果我仍然忘记为您写一些有趣的文章，或者在阅读期间您对TP服务的组织有疑问，我将很乐意在评论中回答。
相关资料