关于在杂货店工作的好处的说法很多，在这里很难独创。 但是，除了开发功能外，还远远没有人知道如何维护产品的“健康”以及在食品公司中可以做什么。 我们将告诉您我们在Juno上如何操作产品，以及操作部门和技术专家如何参与其中。
我们并没有宣称自己的道路是最正确的，而是不断地尝试，犯错误并尝试从错误中学习。 希望我们的经验对您有所帮助。
关于我们： Juno是在美国市场运营的乘车隐藏服务，并且是Gett集团公司的一部分。
Juno用Go，Swift，Kotlin，Python，React.js语言编写代码，作为移动应用程序团队，后端，前端，数据科学，技术运营支持的一部分，创建了一项服务，已成为成千上万驾驶员和成千上万新居民的日常生活的一部分约克。
什么是产品管理
让我们了解在Juno中进行操作的过程，并尝试将其分解为组成部分。
我们为自己确定了三个关键组成部分：
- 业务办公室
- 指标和监控
- 事故调查
操作产品
的目的是及时应对新出现的问题和变化，无论其性质如何。
为此，您需要：
- 定义系统健康指标
- 了解系统内的更改如何影响指标
- 了解市场变化如何影响绩效
- 了解变化何时会成为问题
使用这种方法，业务决策基于数据。 我们的运营团队在纽约工作，因为Juno服务目前仅适用于该大都市的居民。
团队的每日任务清单如下所示：
- 跟踪并快速响应法规变化。 常见的变化包括新收费公路的出现和机场驾驶员等候区的转移。 一旦我们收到有关此类事件的信息，员工就会离开该地点以正确更新地图并分析可能的问题列表。 当开发团队更新服务器上的地图时，员工将测试“现场条件”中的更改并确保其正确运行。
- 进行“现场”研究。 当我们在纽约推出这项服务时，计划首先招募一定数量的驾驶员，以确保该服务在城市任何地区的稳定运行。 因此，几个月来，第一次加入我们的驾驶员在没有乘客的情况下开车，仅偶尔收到来自Beta测试人员的旅行。 这些旅行不足以收集必要的信息。 然后，我们决定将操作团队派往“现场”，以评估服务质量并找出驾驶员对应用程序的投诉。 事实证明这种方法很有用，在发布重大更改或检验假设时，我们会不断使用它。
- 新闻“事件日历” -可能影响旅行数量和质量的事件，节假日和天气事件的列表。 这有助于了解和预期关键指标的变化（例如，出行次数或在线驾驶员的数量），这些变化对于明斯克的开发团队而言并不明显。 可以查询一些事件（天气情况，超级碗决赛，马拉松比赛，自行车比赛等），但是有些事情比较困难。 例如，在工作的第一年，令我们惊讶的是斋月大大影响了愿意接受订单的驾驶员数量。 事实是，在美国，许多穆斯林都是司机，他们不会去度假。 在明斯克期间，很难考虑到这样的事实。
- 跟踪业务指标的变化。 在启动Juno和旅行次数迅速增长的第三个月，我们发现在线驾驶员不足，这影响了汽车交付的时间和乘客与我们同行的愿望。 事实证明，有竞争对手发起了一项运动，以保证驾驶员在早上和晚上的高峰时间增加旅行费用。 这些信息很快被传输到明斯克，并且在短时间内我们也有机会提供了这样的条件。 这一步帮助我们吸引了司机，并继续增长。
指标和监控
在Juno中，所有团队都有指标，我们同意将其划分为：
业务指标是衡量产品“健康”的一系列指标。 我们有条件地将它们分为两部分：
- 在线上 显而易见的是，在线驾驶员和乘客的数量，按状态显示的旅行次数。 不那么明显的是新用户的数量，从屏幕上显示出旅行的初步价格到预订旅行的转换，特定区域内汽车的平均等待时间，机场排队的速度等。
- 下线 并非所有信息都可以快速地实时获得和处理，并且并非总是必要的。 当我们为驾驶员或新功能计划促销时，我们对A / B实验的长期趋势或用户反应感兴趣，无论它是新设计，新功能还是额外折扣。
要基于收集的指标创建分析报告，我们使用Tableau。 对于此类报告，我们负责商业智能（BI）团队。 他们在杂货店团队旁边的特拉维夫办公室工作。 两个团队都与纽约的同事紧密合作，这使基于BI的分析师可以评估所采取措施的成功程度，为在“领域”进行验证制定假设并调整产品开发计划。
另一方面，有许多技术指标会以某种方式影响整个系统。
技术指标 -一系列指示各个组件无错误运行的指标，在此基础上得出结论，系统整体正常运行。 它们显示了服务之间的调用花费了多少时间，消耗了多少内存，以及在它们之间传输消息时是否存在任何严重错误。 Juno中有很多这样的指标。 它们在某种程度上是多余的，但是在紧急情况下，它有助于快速找到问题的原因。 跟踪和使用技术指标可帮助我们：
- 仪表板 -显示系统的重要生命体征。 每个开发团队都会编译自己的一组度量标准，以帮助他们了解特定更改如何影响委托给他们的微服务。 因此，例如，一个团队监视与向驾驶员付款和乘客付款相关的指标，而另一组则查看负责驾驶员搜索时间或接收到的坐标数的指标。
- 日志 我们记录来自移动设备和后端微服务的事件。 在2017年，它们每周占用400-500 GB数据，到2018年这一数字翻了一番。 我们对以下事件感兴趣：微服务对外部信息源的调用，对其他微服务的调用，对客户端的已接收和已发送请求，各种错误（业务和技术错误）。 值得注意的是，信息是匿名的：个人数据（例如密码和银行信息）不会被记录。
为了监视性能，我们使用Grafana和Prometheus。 在开发新服务或添加新功能时，开发人员将必要的指标添加到服务中，然后每个团队为自己设置警报。
借助定制的警报，技术支持团队可以进行初步分析，并将问题升级为开发团队或业务团队，以进一步解决。
如果问题是技术性的，并且威胁到服务的正常运行，则技术支持团队会造成生产事故。 由于采用了自动化流程，因此可以立即通知利益相关者，包括客户支持团队（客户服务aka服务台aka L1支持），该团队正在准备接听大量电话。
事故调查
随着时间的流逝，我们得出的结论是，在每次严重事件之后，都会发生一种“汇报”。 我们正在对流程进行更改，以帮助将来避免或更好地处理类似事件。
上面提到的元素：指标，仪表板，警报和日志有助于了解发生了什么。 团队坐在一起，分析技术和业务指标的变化，将错误考虑在内，并自己汲取教训。
我们必须处理生产事故，以及无法迅速回答“发生的事情”的任何其他情况。 在这里，技术支持团队会提供帮助（TechSupport，也称为L2支持）。
技术支持中解决了哪些问题？ 人们认为这很无聊，就像IT人群系列中那样，地下室的三个书呆子只是按照他们所说的去做：“尝试关闭并打开计算机。” 实际上，问题变得复杂而有争议。
第一阶段的支持（客户服务）是按照“跟随太阳”（跟随太阳）的原则进行组织的。 通过这种方法，无需夜班即可全天候为用户提供支持。 在欧洲，在特拉维夫和美国时间都在波特兰设有办事处。 该团队的任务是倾听和理解驾驶员或乘客的“疼痛”，以保持镇静，并在可能的情况下提供帮助。 在此工作的人员应对有关服务操作的问题负责。 同时，该团队不是“技术人员”，一旦有必要深入了解技术差异时，便将请求重定向到技术支持团队。 该团队在明斯克工作，是开发中心的一部分。 这些家伙专门解决技术问题，不直接与驾驶员和乘客沟通。 团队任务：事件调查和流程自动化。
在发生生产事故的情况下，技术支持团队的任务如下：在部署过程中发现错误或发生故障，我们注意到并修复了问题，但从产品管理的角度来看，我们仍然需要弄清楚它如何影响系统以及需要恢复哪些内容：
- 数据是否损坏或完整性受到侵犯？
- 此事件如何影响用户？
- 所有用户都会受到影响吗？
- 什么可以解决？
问题很简单，但是要回答这些问题，您需要非常了解系统如何工作以及事件期间行为如何变化。 在回答问题时，值得考虑正在进行的部署过程，因为每分钟都有可能发生变化。
例如，当需要技术支持才能使产品正常工作时，请考虑“我没有出差”的情况。 驾驶员接了另一名乘客，并进行了一次我们的乘客不想支付的旅行。 在这种情况下，当用户尝试不支付所提供的服务费用时，有必要区分合法请求和欺诈尝试。
如果请求反复到达，则技术支持团队将其自动化，并以Web应用程序的形式提供给用户支持团队。 通过这种方法，您可以减少处理用户请求所需的时间，而不必“使”技术支持团队“膨胀”。 但是，随着这些人员的成长并移至其他开发团队，技术支持工程师的空缺总是对我们开放。
条条大路通罗马
在本文的框架内对技术支持团队的工作进行详细描述并非偶然。 碰巧的是，它变成了一个信息从所有来源流动的地方。 单点接触减少了口译员的数量，因此减少了失真的数量。
这并不意味着技术支持团队是操作产品管理的主要环节，因为产品公司是生命有机体：所有器官都是重要且必要的。 选择对人更重要的东西是不可能的-脑或心脏，肺或循环系统。 只有所有器官的协调发展和相互作用才能保证身体或IT公司的健康运转。
对您和您的产品健康！