Доверие

Возможно, меня можно обвинить в предвзятости и безмерном обожании Wechat. Обоснованно ли пусть судят другие. В любом случае, Wechat это уникальное явление среди всех IT-проектов всего времени. И тут я попытаюсь раскрыть вопрос What makes it special

В статье в равной мере будут упоминаться Wechat(продукт корпорации Tencent) и Alipay(продукт корпорации Alibaba). Пусть это не вводит вас в заблуждение. Это два кита, это два краеугольных камня китайского интернете и китайского общества, и если что-то появилось у одного это появится и у другого в самом скором времени.
Alipay принадлежит 53.8% рынка платежей, а Wechat 39.9%.
Вы скажете а как же карты. Ну, предлагаю вам найти на сайте одного из крупнейших экваеров Китая Meituan хоть одно решение кассы, где можно использовать карту. Все, абсолютно все заточено под Alipay и Wechat.
В этом плане, кстати, мудрые китайцы всецело понимают важность конкуренции. Авиакомпаний с государственным капиталом было создано 3. Сотовых операторов 3. Банков 4. Китайцы прекрасно знают, чем чревата государственная(или иная) монополия и стремятся их разделить. Когда China Southern начала слишком уж выделяться из конкурентов ей было предложено в добровольно-принудительном порядке выделить часть капитала на создание дочки Xiamen Airlines. Точно так же из China Eastern выделили Shanghai Airlines. Air China Shenzhen Airlines.
Точно так же дело обстоит и в онлайн-платежах. Пускай Alipay и Wechat( которым государство одинаково способствует) вечно догоняют друг друга. Всем от этого только благо.
Но вернемся к теме. И рассмотрим ее на практическом примере.
Недавно я ездил в командировку. И так как из-за пандемии встречается довольно много параноиков, которые хотят подтверждения, что я не болен коронавирусом я решил взять справку о том, что я им не болен. Что я для этого сделал? Ну, сходил в ближайшую больницу, сдал мазок. А дальше?
Зафолловил аккаунт больницы в вичате, нажал на результаты анализов

Ввел телефон, ФИО, номер ID, получил СМС

И нажал на скачать справку

Не заметили здесь секурности? А она есть(с)
В предыдущей статье я писал, что одним из методов аутентификации пользователя является его мобильный телефон. Сим-карту в Китае возможно заиметь только после предоставления биометрии лица. И после ввода эти данных можно отправить запрос соответствует ли ФИО и ID. Если ФИО пациента соответствует с ФИО, на которые был зарегистрирован номер, на который отправили СМС с кодом это 99%, что результаты анализов хочет получить сам пациент.
Wechat и Alipay доверяют. Доверяют все без исключения. Прекрасным примером служит их рейтинг.
У Wechat это Wechat Pay Points, у Alipay Sesame Credit. Высчитывается он тайными алгоритмами, которые никому не известны, но их результат и его влияние на себя может испытать каждый
1) он выше 350 можешь им нормально пользоваться
2) он выше 550 можешь без залога брать в аренду павербанки, зонтики, велосипеды
3) он выше 600 можешь получать chargeback мгновенно. Вот буквально не понравились тебе купленные на Таобао туфли и ты жмешь возврат. Деньги мгновенно возвращаются, а у тебя есть уведомление отправьте нам товар обратно на протяжении 15 дней
4) выше 700 брать авто в аренду без залога. Буквально оставил заявку на авто в аэропорту и тебе скинули его геолокацию. Пришел, отсканил QR-код и поехал
5) выше 900 это основание подать в банк заявку на снижение процента по ипотеке. Взял ты ее под стандартные 3,8%, отправил справку из Wechat о своем >900 рейтинге тебе ее снизили до 2,5%. Одна моя знакомая(в рамках программы поддержки социально значимых профессий она учитель, снизила ее себе до 0,1% годовых. Но справку из Wechat/Alipay тоже потребовали
6) 1000(максимально теоретически возможный) не знаю, что там разблокируется за функционал.
Опять же, реальный пример аренда жилья. Когда я регистрировался в Ziroom, они какой-то внутренней магией посчитали, что мой рейтинг такой-то.
Как я снял квартиру? Выбрал в приложении понравившиеся и нажал посмотреть. После этого мне выдало время и 15-минутный код от замка. Я посмотрел, выбрал, год пожил. Потом переезжал в Шеньчжень и возвращал ее. Я нажал в приложении вернуть квартиру

И уехал. Уже в поезде меня догнало сообщение подтверждаете ли вы баланс счетчиков

Я нажал да и ехал дальше. Наутро я получил полный расчет и 400 юаней переплаты вернулись на счет.

При этом не путайте Ziroom с шарагами вроде AirBNB. На основании контракта с Ziroom я без лишних движений оформил себе налоговый вычет на аренду жилья(скрин из приложения налоговой). Для этого мне понадобился только номер контракта и мое ФИО/ID

Я вообще к чему Подобный уровень доверия сервиса к пользователю, немыслимый, невозможный уровень доверия возможен только тут.
И именно на основе Wechat/Alipay
Именно поэтому все конкуренты жалкое подобие.
Можно как угодно говорить, но Alipay и Wechat доверяю и я. Да, они параноидальны, да, они могут заблочить аккаунт до подтверждения чего-то там, да, они нещадно отслеживают ненормальные транзакции и блокируют всяких менял, да, они могут отрапортовать в банк и ваш счет закроют(на эту тему чаще всего слышен вой со стороны нелегальных менял и обнальщиков). Но если вы спросите меня я верю им на 100%.
Вы можете спросить любого китайца доверяет ли он им. Вы услышите много жалоб на тему привязал карту и потребовали подтвердить, настучали в банк на тему большого перевода без обоснования, потребовали скинуть распечатку транзакций из банка. Но оборвав их и спросив веришь? каждый ответит да.
И именно на стыке доверия к Alipay/Wechat со стороны государства, населения, банков и сервисов и рождается нечто подобного масштаба.
Говорите, что хотите, но именно Wechat первое, чего мне не хватает за границей.
Спасибо за внимание

Существует открытый проект COVID-19 CovidSim Model, написанный на языке C++. Существует статический анализатор кода PVS-Studio, который умеет хорошо находить ошибки. Однажды они встретились. Познайте хрупкость алгоритмов математического моделирования и почему нужно прикладывать максимум усилий к качеству программного кода.

На днях мне понадобилось кое-что найти на GitHub, что является началом этой маленькой истории. Изучая результаты поиска, я случайно набрёл на проект COVID-19 CovidSim Model. Недолго думая, я решил проверить его с помощью анализатора PVS-Studio.

Проект оказался совсем крошечным. В нём всего 13 000 строк кода, если не считать пустые строки и комментарии. И ошибок там тоже почти нет. Но одна ошибка настолько проста и красива, что я не могу пройти мимо!

void CalcLikelihood(int run, std::string const& DataFile,                    std::string const& OutFileBase){  ....  double m = Data[row][col]; // numerator  double N = Data[row][col + 1]; // denominator  double ModelValue;  // loop over all days of infection up to day of sample  for (int k = offset; k < day; k++)  {    // add P1 to P2 to prevent degeneracy    double prob_seroconvert = P.SeroConvMaxSens *      (1.0 - 0.5 * ((exp(-((double)(_I64(day) - k)) * P.SeroConvP1) + 1.0) *      exp(-((double)(_I64(day) - k)) * P.SeroConvP2)));    ModelValue += c * TimeSeries[k - offset].incI * prob_seroconvert;  }  ModelValue += c * TimeSeries[day - offset].S * (1.0 - P.SeroConvSpec);  ModelValue /= ((double)P.PopSize);  // subtract saturated likelihood  LL += m * log((ModelValue + 1e-20) / (m / N + 1e-20)) +        (N - m) * log((1.0 - ModelValue + 1e-20) / (1.0 - m / N + 1e-20));  ....}

Серьёзный научный код. Что-то считается. Формулы. Выглядит всё умно и обстоятельно.

Вот только все эти вычисления разбиваются о человеческую невнимательность. Хорошо, что на помощь может прийти анализатор кода PVS-Studio и указать на баг: V614 [CWE-457] Uninitialized variable 'ModelValue' used. CovidSim.cpp 5412

И действительно, посмотрим внимательнее на это:

double ModelValue;for (int k = offset; k < day; k++){  double prob_seroconvert = ....;  ModelValue += c * TimeSeries[k - offset].incI * prob_seroconvert;}

Перед нами простая и одновременно страшная ошибка: неинициализированная переменная. Этот алгоритм может насчитать всё что угодно.

Собственно, на этом всё. Пояснять тут нечего. Остаётся только вновь напомнить, что разработчики научных библиотек и научных приложений должны прикладывать дополнительные усилия для обеспечения качества кода. Падение обыкновенного приложения, скорее всего, будет стоить намного дешевле, чем использование некорректных результатов вычислений в научных, медицинских и прочих целях.

Это уже не первая наша статья на эту тему:

• Анализ кода ROOT фреймворка для анализа данных научных исследований
• NCBI Genome Workbench: научные исследования под угрозой
• Большой Калькулятор выходит из-под контроля

Используйте статический анализатор кода PVS-Studio! Польза от своевременно найденных ошибок может быть колоссальной. Спасибо за внимание.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. COVID-19 Research and Uninitialized Variable.

Весна 2020 показала, что благодаря DevOps-практикам многие бизнесы смогли быстро перестроить продукты и перейти в онлайн, сохранив работоспособность. Оказалось, что от зрелости практик DevOps зависят не только результаты бизнеса, но и само его выживание.

Наши встречи на конференции DevOpsConf концентрировались не только на инструментарии инженеров, а еще и на процессах, для которых эти инструменты нужны. Кажется, этого недостаточно, чтобы бизнес увидел, как извлечь из DevOps максимум пользы для продукта.

Поэтому мы добавили фокус на том, как людям в разных позициях определить, какой зрелости DevOps-практик удалось добиться и как сознательно выбрать цели технического развития в своей организации и команде. Иными словами, я хочу увидеть, где на поле DevOps я сейчас нахожусь, и каков мой следующий шаг.



Основные измеряемые характеристики DevOps это стабильность работы приложений и производительность IT-команд, от идеи до выкладки фичи на продакшн. Поэтому мы много говорим о time to market и мониторинге и продолжаем технический трек.

А ещё IT-команды состоят из живых людей, которые не только могут выдавать хорошие KPI, а ещё и делают заведомо полезную работу. Ведь если DevOps-подход завоевал популярность в мире, то, наверное, это кому-то нужно. Для вас мы повстречались с Product Owners и бизнесменами, которые не всегда знают, что такое DevOps (как будто мы знаем :D) и расспросили их о том, что же им важно получить от технарей. В чём эта самая польза.

Первым делом пришлось поменять свой словарь и способ общения. Мы говорили не нашими привычными терминами, а старались использовать язык продактов. Даже в качестве способа общения мы выбрали CustDev-интервью, как и принято в продуктовом мире. Эти интервью подтверждают или опровергают наши гипотезы о том, что же важно в работе над продуктом со стороны бизнеса.

Вот какие гипотезы мы проверяли на встречах:

• TTM важен для интересов Product Owner-а.
• Стабильность работы приложения влияет на бизнесовые показатели.
• Разработчики зачастую не согласны с мнением PO о том, что и как делать.
• TTM помогает проводить CustDev. Речь не о технике интервью, а о поиске и подтверждении потребностей клиентов и построении компании.

Я беседую через с Zoom со своей давней знакомой, которая убеждена, что человеку, который ни разу в жизни не продавал, нечего делать в профессии Product Owner. Она часто появляется в передачах на радио и ТВ, проводит семинары по своей предметной области. Как только режим самоизоляции был облегчён, они с мужем и ребёнком арендовали дом на берегу великолепного озера и на всё лето переехали жить и работать туда. Её компания почти 20 лет на рынке онлайн-услуг. На первом месте по рейтингам в своей предметной области.

Скажи пожалуйста, проводишь ли ты специальную работу по сокращению цикла разработки и запуска фич в продакшн в своей команде?

Ты знаешь, уже нет. Если в 2014 году бутылочным горлышком была производительность айтишников, как разработки с тестированием, так и команды эксплуатации, то уже несколько лет я решаю другую задачу. Как успеть подготовить эксперименты, чтобы команде было, чем заняться (смеётся). Если говорить серьёзно, то сейчас я уверена, что фича будет запущена за срок от шести часов до недели...

Погоди, 6 часов?! Это...

От первой беседы с командой до пользователя. Т.е. уже на проде.

Зачем тебе такая скорость?

Я не ставила такой цели. Скорее, я склоняюсь к мысли, что это естественное следствие тех изменений в инструментарии разработки и эксплуатации и настройки взаимодействия между командами и мной, как представителем бизнеса.

Мы продолжили беседу, и за следующие полчаса Наталья рассказала, что крупные изменения продукта сейчас проходят гораздо увереннее и спокойнее. Основным фактором такого изменения она называет её уверенность в команде и доверие команды к ней.

Следующий мой звонок на Пхукет. Игорь переехал туда несколько лет назад и для этого провел не самые простые переговоры со своим работодателем. Тогда удалённая работа была в диковинку, и все сотрудники работали в офисе в Москве. Сейчас за кадром слышны визги и возня его большой семьи. Его компания тоже лидирует на российском рынке по своему направлению.

Внезапно я стал экспертом по удалёнке этой весной! (смеётся)

Расскажи пожалуйста, какие сознательные шаги ты делал для того, чтобы увеличить стабильность работы приложения и зачем?

Когда мы с техдиром начали эту работу, ещё не были в ходу такие термины, как LTV, customer retention или unit economy. Просто мы представили, что пользователи не очень довольны падением приложения 20% времени...

Во, NPS!

Андрей, не было никакого NPS. Сейчас это технологизированный индикатор того, насколько довольны пользователи. Он не покажет мне деньги. Он не покажет, каково отношение затрат на какой-либо проект и отдачи в деньгах от его реализации.

Тебе именно это отношение важно?

Мне важен рост аудитории. Т.е. её лояльность и приверженность к моему продукту.

Что-то ещё? Как маркетинг связан с аптаймом?

Смотри, налить трафик стоит денег. Будь то прямая реклама или SEO оптимизация, органические переходы. Когда в трафик вложены ресурсы, а на стороне приложения он попадает в черную дыру, то это немножечко потери.

Т.е. для тебя сейчас важно, чтобы приложение было доступно.

Сейчас я спокоен, потому что наш аптайм 4,5 девятки. В течение месяца приложение исправно отвечает на 99,995% запросов.

DevOps сделал своё дело, DevOps может...

DevOps ещё и не это может. В какой-то момент мы посчитали, что наш способ развития, через изменения в лаборатории и проверку на фокус-группах, дороже, чем проверка на малых долях аудитории. Вместо того, чтобы разработать прототип, собрать фокус группу и получить одобрение, а потом на живых пользователях увидеть их разочарование, я могу быстро-быстро проверить трипять вариантов на 0,1% пользователей и выбрать лучший.

Т.е. разработчики наговнокодят что-то быстро на костылях, а потом ты выберешь удачный вариант.

Да, из палок и синей изоленты. (Игорь морщится, потому что я на громкой связи, а рядом дети)

Я вижу здесь две потенциальных проблемы. Во-первых, разработчики недовольны, что часть их работы будет заведомо выброшена. Во-вторых, те фичи, которые выстрелили, остаются костылями.

Поэтому для нас важно управлять техдолгом. Можно сказать, что между бизнесом и IT есть контракт: в течение года не менее 30% времени разработки идёт на разгребание долга. Причём, эти проценты мы считаем совокупно за год. Например, весной 2020 мы перекрыли работу с техдолгом полностью, потому что нам была важна скорость изменения продукта. Нам пришлось искать новые модели использования наших сервисов.

Значит ли это, что за оставшиеся полгода ребята будут уже 40% времени заниматься рефакторингом, изменением архитектуры и выпиливанием костылей, а также работать с производительностью приложения?

Абсолютно.

Дальше Игорь рассказал, что у него появилась возможность работать на опережение. Значительная часть задач направлена на освоение новых технологий и интерфейсов. Первые результаты экспериментов уже доступны пользователям, например общение на естественном языке. При этом на сегодняшний день скорее можно говорить о Research части R&D. Компания осваивает технологии заранее, чтобы использовать момент зрелости технологий искусственного интеллекта для получения конкурентного преимущества.

Если говорить об экспериментах, то настройки приложения разделили на три основные группы:

• Продуктовые. Product owner может включить или отключить фичу, а также раскатать её на заданный процент пользователей или даже конкретный список.
• Настройки взаимодействия сервисов это зона ответственности разработчиков.
• Админские, их крутит команда, которая занимается инфраструктурой.

Любопытно, что первый запрос на разделение настроек пришёл из эксплуатации, когда релизы ещё запускались вручную. 20 релизов в день для изменения настроек это не то, что радовало админов. Уже когда сервис настроек был готов, то это создало техническую готовность крутить ручки владельцам продукта.

Мы также созвонились с ребятами, которые ведут продукт в компаниях, где потенциал для развития DevOps намного больше. Они запускают стартапы или работают на крупного заказчика. Другими словами и больше через боль, они говорили о тех же ценностях для Product Owner-а, что и предыдущие собеседники.

Мы обнаружили, что находки нашего исследования подтверждают те выводы, которые есть в в отчете Google The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling (версия на русском).

Мы выделили четыре основные ценности для Product Owner-ов при использовании DevOps:

• Предсказуемость времени реализации фичи и уверенность в качестве софта это необходимая база для активных экспериментов.
• Надёжность работы прода = деньги. Когда трафик попадает на работающее приложение, то это не только позволяет рационально использовать бюджет на продвижение, но ещё и повышает лояльность пользователей, а значит и долю на рынке.
• Скорость экспериментов определяет успех как для стартапа, так и для бизнеса со зрелым продуктом. Если стартапу важно быстро обнаружить предпочтения пользователей и удачные ответы на них, то зрелому продукту нужно удержание пользователей, стабильность массовой выручки и research работа на будущее технологий.
• Доверие к разработчикам и взаимное доверие разработчиков к продакту. Партнёрские отношения между IT подразделением и бизнес юнитами, когда заключается контракт о способах взаимодействия и этот договор исполняют обе стороны. В терминах DevOps это управление техдолгом, поддержка кода в порядке и вовлечение команды в интерес своих пользователей.

Поэтому на конференции поговорим как о важных технических темах, так и о новых. Например, про доверие расскажет Алексей Пикулев, который готовит воркшоп по диагностике и развитию доверия. Продолжим исследовать инженерные практики и инструменты, а также организацию процессов. Коммуникацию бизнеса с командой и между командами будем обсуждать на уже традиционном процессном треке конференции.

Ребята, не беспокойтесь о том, будет ли на конференции по-прежнему много технических докладов. Потому что мы, члены программного комитета, любим системных администраторов и DevOps-инженеров, которых нет. И даже сами ими являемся.

Большинство активностей на конференции сделаем интерактивными, потому что говорящих голов достаточно в интернете. Ведь каждый сознательный инженер может не только найти видео докладов по нужной ему тематике, но и прочитать статьи (например, статьи по следам всех DevOpsConf в профиле Александра Титова).

Наша цель этой осенью дать каждой компании возможность высадить виртуальный десант из Product Owner-ов, техлидов и инженеров всех мастей. Так, чтобы IT-спецназ сориентировался на местности и вернулся в работу с разработанным планом захвата Вселенной!

В следующих статьях расскажем про CTO, разработчиков и безопасников зачем конференция им.

DevOps Live пройдет онлайн 29-30 сентября и 6-7 октября 2020. В онлайне будет всё, за что сообщество любит наши конференции, и при этом мы вместе исследуем новые возможности онлайна.

Пока до конференции есть немного времени подписывайтесь на рассылку: будем присылать письма с новостями о программе, анонсами докладов (и расшифровками с прошлых конференций), а также с разными сюрпризами. И подавайте заявки на доклады или мастер-классы, если хотите повлиять на развитие DevOps в России. А если вы продакт, которому весь этот DevOps только мешает, напишите в комментариях, как вам удается держаться на плаву.