WTD Moscow #2: Светлана Новикова, «Управление знаниями с помощью матрицы компетенций».

Продолжаем тему управления знаниями на митапе Write the Docs в Москве 14 октября.

Светлана Новикова работает в компании IPONWEB, в офисе которой мы с вами встретимся. Светлана расскажет про матрицу компетенций и как с ее помощью организовать управление знаниями в команде разработки:

Расскажу про саму технику матрицы компетенций, откуда она взялась, почему существует еще с 80х годов, и про то, как мы сделали матрицу 2.0. Мы использовали ее для «ориентации на местности», описав, какие явные и неявные знания есть в проекте, какие навыки нужны разработчику, а затем привязали к ней работу с артефактами знаний, включая, но не ограничиваясь документацией, например, knowledge sharing sessions, тренинги, обучения, тесты на понимание, чек-листы и другое.

Митап уже послезавтра. Регистрация закроется сегодня в 17 по Москве. Успейте зарегистрироваться.

Если не успеваете — посмотрите трансляцию, она будет доступна для всех.

​​Что проверить в документации для заказчика? Что вы не упоминаете других заказчиков!

Опытом делится Николай Поташников на secrus.org.

Слайды: https://quizzical-jang-f3e5a7.netlify.com/

WTD Moscow #2: Николай Волынкин, «Технический писатель 2.0.1».

Ещё один доклад на Write the Docs #2 в Москве 14 октября.

Николай — это я, автор канала @docops.

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

Трансляция прямо сейчас: https://www.youtube.com/watch?v=p7G9VRkhjkA

Слайды: nick.volynkin.gitlab.io/techwriter20.

Версия 2.0.1 в названии — не случайность. Про «Техписателя 2.0» я рассказывал в субботу на конференции SECR. За день получил порцию обратной связи и немного обновил содержание. Надеюсь, что за следующий год обратной связи хватит на 3.0.

Обещаю, «Техписателя Х» не будет.

#writethedocs #writethedocs_moscow

Ретроспектива конференции

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

https://www.tg-me.com/program_man/47

​​Одна из причин, почему тексты в интерфейсе должен писать отдельный человек — не дать дизайнеру напихать в интерфейс пиктограммы без подписей.

Вот что здесь изображено? Я не понимаю половину этих картинок!

Обратная связь по митапу WTD Moscow #2.

Если вы были на митапе WTD Moscow #2 или смотрели трансляцию, пожалуйста, оставьте отзыв. Мы стараемся делать митапы чаще и лучше, так что ваша обратная связь нам сильно поможет.

Заполните форму, это займёт минут пять-десять: https://goo.gl/forms/d5ZInFDnwuNdhmtO2.

Если что, трансляция пока что доступна: https://www.youtube.com/watch?v=p7G9VRkhjkA. Через некоторое время вместо неё мы опубликуем отдельные видеозаписи докладов.

Привет, давайте знакомиться!

Я работаю техническим писателем в Plesk, внедряю практику «документация как код», пишу в этом канале про документацию и управление знаниями, организую митапы на те же темы. Посты в канале обсуждают в чате @docsascode.

Сегодня я смотрю Highload++, на ходу пишу и оформляю конспекты, и сразу их публикую на GitHub. Это эксперимент, он уже точно удачный, так что я и дальше буду так делать.

Если ваша документация болит и требует улучшения — давайте обсудим, пишите @nick_volynkin. Я сейчас не беру заказы на разработку документации, но посоветую вам хорошего аутсорсера.

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

До связи,
Николай Волынкин.

Вадим Мадисон из Авито, «Что мы знаем о микросервисах».

Вадим рассказывает в том числе про требования к документации для микросервиса. Они прям всерьёз требуют документацию и без неё не принимают микросервис от разработчиков. Вот что в неё входит:

— Описание сервиса. В двух предложениях, что сервис делает.
— Диаграмма архитектуры.
— Runbook. (Про них я скоро опубликую конспект из книги Seeking SRE)
— FAQ
— Описание API endpoints
— Labels — к какому продукту, функциональности и структурному подразделению относится сервис.
— Владельцы кода.

Конспект здесь: https://github.com/NickVolynkin/highload-2018/blob/master/1.1-microservices.md

Тернии контейнеризированных приложений и микросервисов
Иван Круглов, Booking.com

Очень толковый доклад о проблеме, двух неудачных и одной удачной попытке решения. Полный конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.2-per-aspera-ad-paas.md

Ключевые мысли:

Мысль 1: не стоит недооценивать способность кода выживать. Если вы что-то написали, этим внезапно будут пользоваться. Если там баги, люди с ними столкнутся и будут требовать исправлений.

Мысль 2: лучше скучный инструмент, который вы можете освоить, чем крутецкий, но слишком сложный.

Мысль 3: стоит заранее сформулировать ожидания пользователей от системы и системы от пользователей.

Мысль 4 (продолжение второй): kubernetes хорош, но важнее подумать о том, как вы будете его интегрировать в сществующую экосистему. Только если вы не стартап, все такие cloud-native.

Data Discovery в микросервисной архитектуре
Николай Голов, Avito

Доклад о том, как создать и поддерживать цифровой двойник всей инфраструктуры данных в большой компании — Persistent Fabric, «помнящая ткань».

Из ответов на вопросы после доклада: Fabric — это ткань, а ни в коем случае не фабрика. Не стройте фабрику данных (джависты, вам!), это тупиковый путь. ))

https://github.com/NickVolynkin/highload-2018/blob/master/1.3-data-discovery.md

«Судя по тому, что половина зала знакома с kubernetes, понятие „pod“ уже все знают».

Ох, смелое допущение. Не пишите документацию с такими допущениями.

Базы данных и Kubernetes
Дмитрий Столяров, Флант

Если вы настолько любите kubernetes, что хотите положить в него вообще всё, в том числе базы данных и другой stateful — вот вам подробная инструкция от Дмитрия Столярова из Фланта.

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

А ещё компания Флант делает инструмент https://github.com/flant/dapp.

Конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.4-bd-k8s.md

Apache Kafka как основа для велосипедостроения
Николай Сивко, okmeter.io

Очередной доклад с Highload 2018. Николай рассказывает о том, как сделать свою time-series database, используя Apache Kafka в качестве WAL (write ahead log).

Краткие выводы. Если вы хотите написать свою специализированную БД:

— Подумайте 100 раз
— разберитесь, как работают взрослые БД
— используйте kafka в качестве wal
— напишите остаток кода

Конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.5-kafka-bicycle.md

Разгоняем обработку событий до 1.6М/сек. Опыт Badoo
Александр Крашенинников, Badoo

Хороший ликбез про построение системы сбора статистики. А ещё Александр хвалит ClickHouse: «Инструмент классный, документация ваще огонь, я сам туда писал».
Конспект тут: https://github.com/NickVolynkin/highload-2018/blob/master/1.6-accelerate-events.md

Немного о том, как я пишу эти конспкты:

1. Смотрю, вроде бы всё понятно.
2. Моргнул.
3. Что это вообще на слайде? О чём докладчик говорит? Ничего не понятно!

Топ ошибок со стороны разработки при работе с PostgreSQL.
Алексей Лесовский, Data Egret

Отличный доклад. Алексей раскладывает все проблемы с PostgreSQL по категориям, перечисляет основные ошибки внутри категорий, предлагает решения.

А ещё как техписателю и иногда докладчику мне нравится вот что:
— Сразу объявил структуру доклада, очень чётко по ней шёл и в конце повторил тезисно. Так слушателям гораздо понятнее, где они находятся. А ещё так запоминается лучше. Будете о чём-то рассказывать — пожалуйста, делайте так.
— Термины вводил сразу на русском и английском. Это помогает сопоставить оригинальный термин с переводом и не плодить зоопарк терминов. Например: «Внешние таблицы (foreigh tables), декларативное партиционирование (declarative partitioning)». Так я тоже рекомендую делать в докладах и документации, особенно в переводах статей.

Ещё у Алексея есть документ с подборкой хороших практик: https://github.com/lesovsky/postgres-commandments/blob/master/README.md.

Конспект доклада: https://github.com/NickVolynkin/highload-2018/blob/master/1.7-postgresql-errors.md.

«Платформа» в Badoo: как мы построили инфраструктурную разработку.
Антон Поваров, Badoo

Доклад про становление инфраструктурной команды, её роль в компании, задачи и взаимодействие с разработчиками и бизнесом.
Конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.8-badoo-infradev.md

Это последний доклад на сегодня. Хорошего вам отдыха, встретимся завтра.

FAQ по архитектуре и работе ВКонтакте.
Алексей Акулович, ВКонтакте

Доклад-экскурсия по архитектуре VK. В конце конспекта — ссылки на другие доклады по конкретным аспектам архитектуры. https://github.com/NickVolynkin/highload-2018/blob/master/2.1-vk-architecture.md

Тем временем, Лана Новикова на Highload провела и законспектировала митап про управление знаниями.

А ещё она уже некоторое время в тайне от всех ведёт канал про управление знаниями. Давайте сделаем тайное явным и вместе подпишемся на @the_know_all.

Делюсь конспектом и слайдами с митапа Управление знаниями по принципам DevOps, очень продуктивная дискуссия получилась

https://gist.github.com/lananovikova10/1e19e169d7365b958b7a4d15491a6b00