Ruvds_прямые эфиры

Недавно в наших соцсетях выступал Александр Чистяков, DevOps с 7-летним опытом и сооснователь Санкт-Петербургского сообщества DevOps-инженеров.

Саша один из топовых докладчиков в этой сфере, он выступал на главных сценах на Highload++, РИТ++, PiterPy, Стачка, всего сделав не менее 100 докладов. В прошлый понедельник он ответил на вопросы зрителей и рассказал про свой опыт.

Делимся записью эфира и расшифровкой.

---

Меня зовут Александр Чистяков, я много лет работаю DevOps-инженером. Я давно консультирую различные компании на тему внедрения DevOps-практик, использования современного DevOps-инструментария и организации инфраструктур таким образом, чтобы все мы могли спокойно спать по ночам, и люди продолжали получить деньги за свои товары и услуги.

В основном я консультировал иностранные компании.

Мы поговорим о том, как люди используют Kubernetes в повседневной практике, зачем это нужно, почему этого не стоит бояться, на что стоит обратить внимание и что будет дальше.
Думаю, что системным администраторам, DevOps-инженерам, IT-директорам, другим специалистам, которые занимаются управлением инфраструктурами (и сочувствующим) это будет полезно.

Как развивался этот ландшафт? Я помню компьютеры, на которых был установлен ROM Basic, и можно было писать программы без установленной ОС. С тех пор много воды утекло. Сначала ОС не было как таковых (точнее, они были написаны на ассемблере). Потом появился язык C и ситуация принципиально улучшилась. Конечно, теперь мы все знакомы с понятием ОС: это платформа, которая позволяет запускать пользовательские приложения и управлять ресурсами, которые у нас есть на этом компьютере. Или на других, если она распределенная. Уже тогда можно было собрать высокопроизводительный вычислительный кластер из своего ноутбука и десктопа так делали студенты в общежитии Санкт-Петербургского политеха году в 97-м.

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

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

Тем не менее, в массовом сознании произошел сдвиг в сторону представления об ОС как о платформе, которая не предоставляет те сервисы, которые были один раз одобрены каким-то стандартообразующим комитетом и оказались закреплены за ней, а просто удовлетворяет нужды пользователей. Каковы эти нужды?

Раньше было принято спрашивать разработчика, на чем он пишет. Были специалисты по C++ (наверно, и сейчас есть где-то), сейчас много специалистов по PHP (они и сами над собой смеются, бывает) и очень много разработчиков на JavaScript. Сейчас набирает популярность Typescript, язык GoLang, в который переключились люди со знанием PHP. Был язык Perl (наверно, и сейчас остался, но сильно потеряв в популярности), язык Ruby. Вообще, приложение может быть написано на чем угодно. Если вы живете в реальном мире, вы, наверно, сталкивались с тем, что они пишутся на чем угодно: на Javascript, на Rust, на C; придумайте название на этом что-то было написано.

И все это надо эксплуатировать. Оказалось, что в такой гетерогенной системе, во-первых, нужны специалисты для разработки на разных языках, и, во-вторых, нужна платформа, которая позволяет запустить сервис в приятном ему окружении и следить за его жизненным циклом. Есть некий контракт с этой платформой, который в современном мире выглядит так: у вас есть образ контейнера (система управления контейнерами сейчас везде Docker, хотя ничего хорошего про него я не могу сказать; о проблемах мы еще поговорим).

Несмотря на то, что человечество движется по некому эволюционному процессу, этот процесс имеет сходимость. В нашей индустрии так получается, что кто-то все еще пишет код на языке Perl (под mod_perl Apache), а кто-то уже на GoLang пишет микросервисную архитектуру. Оказалось, что очень важен контракт с платформой, очень важно наполнение платформы, и очень важно, чтобы платформа помогала человеку. Делать вручную операции для того, чтобы завернуть и запустить сервис, становится очень дорого. Мне приходилось сталкиваться с проектами, где было 20 сервисов и это был не слишком большой проект; я слышал и о ребятах, у которых тысяча разных сервисов. 20 это нормальной количество; и каждый набор сервисов разрабатывает своя команда на своем языке, они связаны только протоколом обмена.

Касаемо того, как устроен контракт для приложения. Есть манифест о 12-факторном приложении 12 правил того, как приложение должно быть устроено, чтобы его было удобно эксплуатировать. Мне он не нравится. В частности, там написано, что надо доставлять конфигурации через переменные окружения; и я уже не раз сталкивался с тем, что в Amazon, например, количество переменных окружения, которые можно передать в Elastic Beanstalk, составляет одну страницу ядра Linux 4 килобайта. И они очень быстро переполняются; когда у тебя 80 различных переменных, 81-ю уже сложно воткнуть. Более того, это плоское конфигурационное пространство когда есть переменные, их надо называть большими буквами с подчеркиванием, и среди них нет иерархии; сложно понять, что происходит. Я еще не придумал, как с этим быть, и мне не с кем это обсудить нет группы энтузиастов, которые были бы против подобного подхода. Если это вдруг кого-то тоже не устраивает напишите мне (demeliorator в Telegram), буду знать, что я не одинок. Мне это категорически не нравится. Этим трудно управлять, трудно передавать иерархические данные; получается, что работа современного инженера состоит в том, чтобы знать, где какие переменные, что они значат, правильно ли они заведены, насколько легко их изменять. Мне кажется, что старые добрые конфигурационные правила были лучше.

Возвращаясь к контракту. Получается, что нужен Docker Image: понадобится непосредственно сам Docker (несмотря на то, что он сам убогий я надеюсь, что их какая-нибудь Microsoft купит и либо похоронит, либо разовьет нормально). Если вас не устраивает Docker, можно попробовать Stack от Red Hat; про него я не могу ничего сказать, хотя мне и кажется, что это должно быть лучше, чем просто ванильный Kubernetes. Ребята из Red Hat уделяют гораздо больше внимания вопросам безопасности, умеют делать даже multi-turned инсталляции, многопользовательские, многоклиентские, с нормальным разделением прав в общем, следят за тем, чтобы управление правами было.

Остановимся на вопросах безопасности. С ней плохо везде, не только на Kubernetes. Если говорить о вопросах безопасности и оркестрирования контейнеров, я большие надежды возлагаю на web assembly, которую делают server side, и для web assembly-приложений можно будет ограничения потребления ресурсов, системных вызовов прикрутить в специальных контейнерах, на Rust. Это будет хороший ответ на вопрос безопасности. А в Kubernetes безопасности нет.

Допустим, у нас есть приложение. Оно представляет из себя Docker-образ, оно 12-факторное то есть, оно умеет забирать вашу конфигурацию из переменных окружения, из файла, который вы смонтируете внутри контейнера. Его можно запустить внутри оно самодостаточно, его можно попытаться связать с другими приложениями через конфигурации, автоматически. И оно должно писать логи в стандартный вывод что, наверно, является наименьшим злом; когда логи контейнер пишет в файлах, оттуда не очень легко собирать. Даже Nginx запатчили так, чтобы можно было собирать логи со стандартного вывода контейнера, это приемлемо (в отличие от передачи конфигурации через параметр). По сути дела, раньше у нас было несколько оркестраторов: Rancher, Marathon Mesos, Nomad; но, как гласит принцип Анны Карениной применительно к техническим системам, сложные технические системы устроены одинаково.

С Kubernetes у нас ситуация, как у авиакомпаний с Boeing 737 MAX он не летает, потому что в нем ошибка, но ничего другого нет, потому что конструкция очень сложная. Я не могу сказать, что он нравится мне как и язык GoLang, и управление через формат YAML, когда у вас есть некий синтаксис, и поверх него ничего нет никаких проверок того, что вы пишете, никаких типов данных. Все проверки, которые вы делаете перед тем, как сделать apply конфигурации в Kubernetes это рудименты. Вы можете попытаться сделать apply неправильной конфигурации, и она применится без вопросов, и получится неизвестно что. Очень легко написать неправильный конфигурационный файл. Это большая проблема, и люди уже начали потихоньку решать её, используя DSL-и Kubernetes на языках Kotlin, даже Typescript. Есть такой проект Pulumi, есть Amazon-овский проект EKS хотя он больше ориентирован на Amazon; Pulumi это такой Terraform, только на Typescript. Я жалею, что до сих пор не попробовал Pulumi, потому что считаю, что в нем будущее. Конфигурация должна быть описана на языке программирования со строгой статической типизацией, чтобы перед применением, которое может потенциально уничтожить кластер, вам хотя бы сказали бы на этапе компиляции, что так нельзя.

Таким образом, на данный момент оркестратор только один. Я знаю, что где-то остались пользователи на MATA, я жму им руку; надеюсь, что Docker Swarm больше никто не использует мой опыт с ним был достаточно негативным. Я верю, что может быть иначе, но не знаю, зачем; никакого дальнейшего развития Docker Swarm я не предвижу, и не думаю, что люди, выпускающие его, что-то сейчас собираются с ним делать. Капитализм; если вы не зарабатываете деньги, то на разработку тратить нечего а их компания последние два года находится в долине смерти стартапов: денег им никто не хочет давать. Можно делать ставки, кто купит их. Microsoft не заинтересовался. Может быть, какой-нибудь Microfocus это сделает, если Docker доживет.
Раз остался один Kubernetes, давайте поговорим про него. Есть прекрасная картинка с пентаграммой из пяти его бинарей; написано, что Kubernetes это очень просто, всего пять бинарников. Но я далек от того, чтобы сложности системы измерять в количестве бинарников, в которые она скомпилирована, и в количестве сервисов, которые составляют ядро системы. Неважно, сколько там бинарников важно, что Kubernetes умеет выполнять, и как он устроен внутри.

Что он умеет выполнять? Вот представьте себе, что вам надо объяснить пятилетнему ребенку, что вы делали на работе. И вот папа, который пытался на Ansible написать playbooks и роли, которые позволят ему сделать blue-green deployment на базе Nginx на хосте и набора контейнеров, которые не регистрируются ничем, кроме tv-ansible, говорит: Знаешь, сынок, я пытался все это время сделать свой собственный Kubernetes. Он плохо работает, он плохо протестирован, я плохо его понимаю, я не знаю всех граничных условий, работает в пределах одной машины, но зато он мой! Я неоправданно много раз такое видел 2 или 3 раза только смотрел, и 2 раза участвовал в написании подобного. Рано или поздно человек, который в таком участвует, понимает, что 4-го раза быть не должно. Это как у моих друзей-автолюбителей, которые однажды восстановили ВАЗ-2101 поставили электростеклоподъемники, флоком салон заделали, покрасили в металлик. Создание своего собственного оркестратора это примерно так. Можно попробовать один раз, чтобы убедиться, что вы умеете, но рекомендовать это всем а не только энтузиастам я не готов. Поэтому управление жизненным циклом, управление состояниями контейнеров это задача Kubernetes.

Он может убедиться в том, что контейнер запущен на том узле, где есть ресурсы, может перезапустить умерший контейнер, может убедиться в том, что, если контейнер не запускается, то на него трафик не пойдет, если будет новый deployment. Кроме того, мы начали со слов о том, что Kubernetes это ОС; где ОС, там должен быть пакетный менеджер. Когда Kubernetes начинался, описания объектов в нем были императивны; stateful сет и описание кода это такие описания, которые работают напрямую, и сверху надо добавить что-то, чтобы было более понятно состояние вашего [??? 18:52 глюк записи]. Собственно, радикальное отличие от Ansible и других подобных конфигурационных систем управления заключается в том, что в Kubernetes вы описываете то, что должно получиться, а не то, как это должно получиться. Вы натурально описываете, какие у вас объекты есть и какие у них есть свойства. Объекты это service, deployment, daemonset, statefulset. Интересно, что, кроме тех объектов, которые можно создавать стандартно, есть и кастомные объекты, которые в Kubernetes можно описывать и создавать. Это очень полезно; это еще и сильно проредит ряды сисадминов и devops-инженеров.

Когда умрет Kubernetes?

Хороший вопрос. Зависит от того, что понимать под словом умрет. Вот Docker мы год назад собирались на конференции в Петербурге, был круглый стол, и мы совместно решили (ну, поскольку мы и есть индустрия, я думаю, там было квалифицированное большинство, и мы вполне могли себе позволить говорить за всех), что Docker уже умер. Почему? Потому что на конференции не было докладов про Docker, хотя ему не так много лет. Про него никто ничего не рассказывал. Рассказывали про Kubernetes, про следующие шаги Kube Flow, например, про использование операторов, про то, как размещать базы Kubernetes. Про что угодно, но не про Docker. Это смерть когда вы насколько плохи, что вы как бы живы, но к вам никто не приходит.

Docker уже умер. Когда умрет Kubernetes давайте подождем лет 5. Он не умрет, он будет у каждого он будет внутри Tesla, внутри вашего телефона, везде, и никому не будет интересно о нем говорить. Я думаю, что это и есть смерть. Может быть, даже не через 5 лет, а через 3. Другой вопрос что придет ему на смену: какая-то громкая новая технология, про которую все будут говорить, возможно, не из DevOps-мира вообще. Сейчас про Kubernetes говорят даже просто для того, чтобы поддержать разговор, и это нормально это модно.

Что не так с Docker?

Все. Это единый бинарь для управления всем, это сервис, который должен быть запущен в системе, это штука, которая управляется через сокет в том числе. Это такой продукт, в котором много кода, который не сильно кто ревьюил, как я думаю. Это продукт, за которым нет, по большому счету, энтерпрайзных денег. В компании Red Hat работают очень умные люди, я их очень уважаю, и, если вы обычный инженер, то вам следует смотреть на то, что они делают, потому что это может определить ландшафт на следующие 5 лет. Так вот, Red Hat выкинули Docker вообще. Они движутся к тому, чтобы его не было. Пока они не могут сделать этого до конца, но они близки, и рано ли поздно они дожмут Docker. У него, кроме всего, что я перечислил, громадная площадь атаки. Безопасность там никакая. Было поднято не так много CVE по нему, но, если посмотреть на них понятно, что, как и в любом другом проекте, где безопасность не во главе угла, ею занимаются по остаточному принципу. Это закон. Безопасность это долго, дорого, муторно, ограничивает разработчика, сильно усложняет жизнь. Правильно сделать безопасность это тяжелый труд, за который надо заплатить. Если поговорить с любым специалистом по безопасности, неважно, какой квалификации вы наслушаетесь страшилок про Docker и историй про то, как все плохо. Они частично связаны с самим Docker, частично с людьми, которые его эксплуатируют, но сам Docker мог бы и помогать людям и некоторые security checks внутри себя проводить; например, не стартовать процесс в контейнере от рута, если не сказано сделать это явно.

Как хранить состояния? Допустимо ли базу данных разместить в Kubernetes?

Если вы спросите DBA, или человека, который за инфраструктуру этой БД отвечал до того, как вы решили ее поместить в Kubernetes, этот человек скажет нет. Я думаю, на многих круглых столах люди скажут, что никаких БД в Kubernetes не должно быть: это сложно, ненадежно, непонятно, как этим управлять.

Я считаю, что БД в Kubernetes могут быть представлены. Насколько это надежно? Ну, смотрите: мы имеем дело с распределенной системой. Когда вы будете ставить БД в кластер, вы должны понимать, что у вас есть требование по отказоустойчивости. Если у вас есть такое требование, скорее всего, то, что вы поставите к себе в Kubernetes внутрь это кластер БД. Много ли людей в современном мире умеют делать нормально кластер базы данных? Много ли БД предоставляют возможность кластеризации? Здесь начинается разделение БД на традиционные реляционные, и на нереляционные. Их отличие не в том, что вторые не поддерживают SQL в том или ином виде. Отличие в том, что нереляционные БД гораздо лучше подходят для работы в кластерах, потому что их изначально писали для того, чтобы БД была распределенной. Поэтому, если для какой-нибудь MongoDB или Cassandra хотите сделать размещение в Kubernetes, я не могу вас отговаривать, но вы должны очень хорошо представлять, что будет дальше. Вы должны очень хорошо понимать, где лежат ваши данные, что будет в случае отказа и восстановления, как идут бэкапы, где находится точка восстановления и за какое время вы восстановитесь. Эти вопросы не имеют отношения к Kubernetes; они имеют отношение к тому, как вы в принципе эксплуатируете кластерное решение на базе обычных баз данных. С NoSQL-решениями проще, они сразу cloud-ready.
Но все-таки возникает вопрос а зачем БД помещать в Kubernetes? Вы можете взять предоставляемую вашим провайдером услугу, managed-решение; вы можете в Amazon взять RDS, в Google тоже managed-базу. И даже географически распределенный кластер этой базы, в случае с Amazon это Aurora, можете установить и использовать. Но, если вы будете ставить географически распределенный кластер базы, прочитайте внимательно документацию; мне доводилось встречать кластера Aurora, состоявшие из одного узла они даже не были распределены на два региона. Более того, второй регион вообще не был нужен. У людей вообще очень странные вещи в головах: они считают, что главное выбрать продукт, а дальше он сам себя обеспечит и заработает, как надо. Нет. Реляционные БД вообще не были готовы к тому, чтобы работать даже в обычном кластере, не говоря уже про геораспределенные. Поэтому, если вы делаете что-то сложное на их базе, ознакомьтесь с документацией.

В принципе, у меня есть опыт эксплуатации БД внутри Kubernetes. Ничего страшного не было. Произошло несколько сбоев, связанных с падением узла; переезд штатно отработал на другой узел. Все под контролем. Единственное, что я не могу вас обрадовать и сказать, что там держалось огромное количество тысяч запросов в секунду.

Если у вас среднее или небольшое решение среднее решение для России примерно соответствует большому новостному агентству типа Ленты то большого количества сложных запросов к базе не должно быть. Если база не справляется, то, наверно, вы что-то делаете не так, и вам нужно об этом подумать. Не пытайтесь бездумно масштабироваться. Перевод некластерного решения в кластер несет свои плюсы, но также и большое количество минусов особенно, если вы возьмете postgres-кластера на базе Patroni или Stallone. Там много граничных условий; я с ними не сталкивался, но коллеги из Data Egret вам с удовольствием расскажут про то, как бывает. Есть доклад Алексея Лесовского прекрасный о том, что будет, если вы попытаетесь вашу базу перевести в кластер, не думая.

Насчет тысяч запросов в секунду. Если у вас есть один инстанс БД, то тюнинговать его по тысячам запросов в секунду это все еще масштабирование вверх. Вы рано или поздно упретесь. Мне кажется, что лучше, если планируется большая нагрузка, рассмотреть горизонтальные варианты масштабирования. Найдите самую большую таблицу в вашей БД, посмотрите, что там лежит, и подумайте, нельзя ли это вынести в нереляционное хранилище. Думайте, как не хранить в реляционной БД то, что вы в ней обычно храните например, логи доступа в систему, которых падает достаточно много, а доступаетесь к ним вы обычно по тому же шаблону, по которому доступаетесь в хранилище ключ-значение. Поэтому, почему бы не писать логи в Cassandra? Это вопрос к архитектору. Держать небольшой и не очень нагруженный инстанс базы в Kubernetes это самое то, потому что за него начинает отвечать магия оператора.

В принципе, если посмотреть на то, что из себя представляет Kubernetes как ОС и платформа, то это конструктор сделай сам. Там есть все, чтобы вы построили микросервисную архитектуру, в том числе с возможностью хранения стейтов на дисках, организации телеметрии, мониторинга, алертинга. Это делается средством Helm это пакетный менеджер Kubernetes. В интернете огромное количество опенсорсных, публично доступных Helm Charts. Самый просто способ поднять инфраструктуру проекта это взять Helm Chart, который ставит ваше приложение, ваш сервис, если этот сервис это база данных Redis, PostgreSQL, Patroni что угодно; начать его конфигурировать, и применить эту конфигурацию. Она полностью декларативна; все, что можно предусмотреть, авторы Helm Charts обычно предусматривают. Ваше приложение тоже лучше всего релизить при помощи Helm. Третий Helm не содержит сервисов на стороне кластеров; второй содержал, у него был постоянно работающий от администратора кластера сервис, необходимый, чтобы раскладывать по namespace релизы, но третий Helm эту дыру в безопасности закрыл.
Helm это такой шаблонизатор на базе синтаксиса шаблонов GoLang. Он берет список переменных, которые представляют собой неплоскую структуру (она, слава богу, иерархическая записывается в YAML); эти переменные с помощью Helm расставляются по нужным местам в Helm Templates, дальше применяете это все в какой-то namespace, там запускаются ваши коды, сервисы, ваши роли создаются. Есть генератор скаффолдинга, который позволяет Helm Chart написать, не приходя в сознание. Единственное, что мне не нравится это необходимость знать синтаксис шаблонизатора GoLang и условных ветвлений в самом Helm; они сделаны по lispовому принципу, с префиксной нотацией. Хорошо, что это еще нравится кому-то, но это заставляет каждый раз голову переключать. Ну, переживем это.

Теперь немного о том, что будет дальше. Я уже напоминал операторы; это такие сервисы, которые живут внутри кластера Kubernetes и управляют жизненным циклом другого, большего приложения. Достаточно сложно. Можно считать, что оператор это такой ваш кремниевый домашний site reliability engineer; наверняка в дальнейшем люди будут писать все больше операторов, потому что никому не хочется держать смену людей 1-го уровня поддержки, которые бы следили за графиком Nagios, замечали бы outages и предпринимали действия вручную. Оператор понимает, какие состояния системы возможны; это конечный автомат. Теперь концентрирование знаний человечества, написанное на языке GoLang или подобном, компилируется, ставится в кластер и делает большое количество работы за вас: добавляет или удаляет узлы, реконфигурирует, следит за тем, чтобы упавшее поднималось, чтобы данные пристыковывались к нужным кодам с того места, где они находятся. В общем, управляет жизненным циклом того, что под ним установлено. Операторы сейчас есть буквально для всего. Я вот развлекался тем, что при помощи оператора Rook ставил sev прямо в кластер Kubernetes. Я посмотрел на то, как это происходит, и я очень доволен, и думаю, что операторов нужно больше, и все мы должны участвовать в их тестировании. Время, которые вы затрачиваете на исправление чужого оператора это подарок человечеству. Вам больше не нужно будет делать одну и ту же работу много раз. Вы сможете эту работу в отчуждаемом виде положить в репозиторий, и дальше умная программа будет делать ее за вас это ли не счастье.

Я скачал книгу Red Hat они ее раздают бесплатно про то, как устроены Kubernetes-операторы и как написать свой, рекомендую вам пойти на их сайт и тоже скачать, книга очень интересная. Когда я ее прочитаю полностью, может быть, разберем вместе какой-нибудь оператор.

Кто поддерживает Swarm? Кроме Docker Inc?

Никто. А Docker Inc. уже раздербанили на две половины, и одну половину куда-то продали. Я не слежу за тем, что у них происходит; одно время они называли продукт Mobi, но это была open source-версия, то есть, была не открытая версия. И что-то продали с правами, а что-то не продали. Для меня это выглядит как больной перед смертью потел люди пытаются хоть как-то извлечь вложенные деньги. В общем, никто не поддерживает.

Master/Slave

Это работает. Если в реляционной БД перестанет работать master/slave, то на этом мир закончится. Kubernetes никак не мешает работе БД; единственное, что он привносит это разные health checks, которые можно при желании отключить, и, в принципе, управление состоянием. Желательно не отключать ваш оператор, который управляет БД, должен видеть ее состояние.

Как называется книга Red Hat?

Kubernetes Operators, так и называется. Там уточка нарисована. Книга OReilly, сейчас сделали редизайн обложек; довольно много книг в сотрудничестве с Red Hat выпустили. У Red Hat есть еще 3 или 4 книги по Kubernetes, которые можно скачать бесплатно: например, Kubernetes Patterns, gRPC. Протокол gRPC, хотя и не имеет прямого отношения к Kubernetes, применяется многими для обмена данных между микросервисами. Кроме того, он в балансировщиках следующего поколения применяется, например, в Envoy.

Что такое SRA?

Это такой человек, который понимает временные рамки изменений, происходящих в распределенной системе. Грубо говоря, он понимает, сколько уже вы в этом месяце полежали, сколько еще можно, можно ли давать разрешение на релиз. Заведует ключами от бэкапов, рекавери-планами, вопросами восстановление после сбоя, вопросами обслуживания инфраструктуры промышленного приложения, которое должно работать 24/7. У него есть метрики по состоянию и бизнес-состоянию приложения в части application metrics сколько latency, где и сколько запросов; те самые 4 золотых сигнала. Дальше SRA на основании этих метрик может предпринимать шаги по приведению системы в боеготовое состояние обратно, у него есть план того, как это сделать. От классического DevOps почему-то это не требуется, он просто помогает разработчику довести приложение до релиза, вообще куда-то выкатить. А SRA еще и противостоит потоку запросов с разных сторон.

Я обещал поговорить про безопасность. Вы знаете, это достаточно молодая тема в Kubernetes. Я знаю только самые основы: например, то, что не следует запускать приложение в сервисе от рута, потому что, как только это происходит, у него есть доступ ко всему в namespace, права суперпользователя, и можно попытаться проломить ядро хостовой системы, что, наверно, получится (и всякие другие операции выполнять от рута). Не надо давать хакерам подобную подсказку; по возможности, давайте пользователям как можно меньше прав и хорошо обрабатывайте пользовательский инпут. Мне кажется, что, если говорить о безопасности Kubernetes, его надо выносить куда-то в закрытые контура, которые сейчас есть. Или, если действительно хотите заняться вопросами безопасности, следует обратить внимание на проект Cilium. Он умеет использовать сетевые фильтры, разграничение прав сетевого трафика на базе BPF это работает лучше, чем iptables. Это будущее. Мне кажется, что за пределами Калифорнии его особо никто не использует, но можно уже начинать. Может быть, будет какой-то еще проект, но я в это сомневаюсь. У человечества вообще мало рабочих рук.

Поэтому про безопасность мне особо нечего сказать. Есть различные варианты mounted tenancy в Kubernetes, но там надо сидеть с карандашиком и разбираться в том, что люди сделали, какую уязвимость закрыли, имело ли это смысл, применимо ли это к вашей модели угроз. Кстати, я рекомендую начинать с поиска описания того, как строится модель угроз, и построения ее для себя. Есть более-менее формальные методики. Нарисуйте, посмотрите на нее, и, может быть, произойдет озарение, и вы поймете, что вам нужно, а что не нужно в текущей ситуации. Может быть, будет достаточно загнать весь Kubernetes в закрытый контур. Это, кстати, правильное решение; я с таким сталкивался, и это непробиваемо. Если получить доступ к системе можно, только предъявив пропуск на вахте, и внутри никакого интернета нет, а обмен идет через какой-нибудь специальный gateway, находящийся в DMZ, и его сложно сломать, потому что он необычно написан тогда это хорошо защищенная система. Как это делать техническими средствами ну, надо мониторить текущий рынок решений. Он сильно меняется, безопасность горячая тема. Игроков пытается быть много, но кто из них врет, а кто нет я не берусь говорить. Хотя Red Hat, скорее всего, не врет, но он и не впереди всех. Надо просто сделать research (и мне тоже), потому что пока непонятно.

Поговорим о том, что еще в кластере Kubernetes должно быть. Раз уж у нас есть возможность ставить туда приложения бесплатно, и мы не боимся хранить там БД. Кстати, если у вас Managed Kubernetes, то нет вопросов о том, где хранить БД: у вас есть отказоустойчивое хранилище, в том или ином виде (часто в виде блочных устройств) подводимое из облака, в котором размещен Managed Kubernetes. Можно спокойно диски с этого хранилища размещать у себя по кластеру и с помощью snapshots забирать консистентные бэкапы. Только не забывайте, что snapshot это не бэкап, нужно еще отснапшоченное куда-то скопировать. Это очевидно, но очевидные вещи хорошо повторять, чтобы не забывались.

Очень важно, когда у вас есть платформа с микросервисной архитектурой, сделать так, чтобы она прослеживалась, чтобы было observability, чтобы вы могли понять, где находятся запросы и где они теряют время, и так далее. Построение такой платформы это большой труд. Вам понадобится Prometheus. Он понадобится потому, что является проектом Cloud Native Computing Foundation; он специально предназначен для того, чтобы мониторить Kubernetes. Содержит огромное количество экспортеров, сборщиков метрик; некоторые приложения нативно содержат все его dashboard. Если ваше приложение их не содержит, то приделать к долгоживущему приложению dashboard Prometheus это дело 20 минут. Хотя почему-то никто не приделывает. По моему опыту это происходит из-за того, что люди держат свои продукты в облаках. Там есть Amazon CloudWatch, Google StackDriver, и туда можно точно так же отправлять метрики хотя это будет стоить денег. То есть, если люди все равно платят за инфраструктуру, то они платят и за средства мониторинга, прилагаемые к ней. Тем не менее, Prometheus бывает очень удобен, если у вас есть несколько разных мест, откуда вы забираете метрики, если облако не в одном месте, если оно гибридное, если у вас есть машины on-premise и нужна централизованная инфраструктура. Тогда Prometheus ваш выбор.

Что вам еще понадобится? Понятно, что там, где Prometheus, там и Alert Manager нужен. И еще понадобится какой-то вариант распределенной трассировки ваших запросов. Как это сделать в Kubernetes ну, взять какой-нибудь продукт типа jaeger, или zipkin, или что там сейчас на топе; также Cassandra, чтобы хранить ваши трейсы, также Grafana, чтобы их визуализировать. Насколько я понимаю, в Grafana эта функция появилась недавно, но это не повод не внедрять. То есть, вы можете вручную собрать среду, в которой приложения будут [глюки 49:14] (иметь?) к этому времени выполнения и счетчики, и еще метрики, пригодные к выстраиванию, визуализации ваших трейсов, распределенных: где приложение сколько времени проводит?

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

Мне кажется, я рассказал все, что хотел рассказать. Повторю еще раз основные положения.

Первое: Kubernetes избавляет вас от необходимости писать механизм отказоустойчивой замены одного контейнера другим самому на Ansible Engine X.

Второе: Kubernetes никуда не исчезнет. Он может умереть, но перестать им пользоваться уже невозможно, он захватил большую часть рынка. На вопрос когда умрет Kubernetes: я хочу спросить а когда умрет WordPress? А ему еще жить и жить Давайте очередность установим: сначала WP, потом Kubernetes.

Итак, Kubernetes с нами. Интересен скорее не он сам, а интересны те сервисы, которые накручиваются поверх это операторы и Custom Resource Definition. Возможность взять и написать свой ресурс, который будет называться PostgreSQL cluster, описать его одной YAML-портянкой и забросить в кластер.

Что еще будет? Еще будет возможность управления всем этим, статически типизированные языки программирования такие, как GoLang и TypeScript. И в Котлин я очень верю на нем уже написано очень много классных DSL. И еще будет написано.

Еще появятся платные Helm Chart, платные приложения, которые можно запускать on-premise, какие-то лицензионные, по подписке. Будет интеграция разных сервисов собственно, она уже есть, например, DataDog уже интегрируется с Kubernetes. И новые ребята, которые будут появляться на рынке мониторинга-алертинга, тоже будут интегрироваться с Kubernetes, по понятным причинам. Любой облачный продукт не пройдет мимо Kubernetes, так или иначе. Это та платформа, в которую каждый будет целиться.

Но все это не значит, что Kubernetes хороший, и ничего нельзя придумать лучше. Я сравниваю его с тем, что было раньше с решениями Amazon: ECS, Elastic Beanstalk. Кто сталкивался с ними знает, что в моей давней аналогии что одно, что другое было бы не просто 737 MAX, а 737 MAX, сделанным из изоленты и пластилина. Поэтому основные игроки Amazon, Microsoft Azure, Google все уже в Kubernetes.Наверно, Яндекс и Mail.ru тоже, но я за ними не слежу. Это такое общее будущее. Такое плохое, но достаточно хорошее общее будущее, на которое пока все согласны. Во что это все мутирует дальше, надо спрашивать у Red Hat они умнее меня.

Как себя Java чувствует в Kubernetes?

Нормально.

Какую ОС используете на своем ПК?

На обоих MacOS.

Берут ли сейчас активно DevOps-специалистов на удаленку?

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

---

Что было ранее

1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
18. Как Data Science продает вам рекламу? Интервью с инженером Unity
19. Как я переехал в Лондон c Revolut
20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
21. Как организовать IT-конференцию и не сойти с ума

Пару дней назад на нашем ютубе выступала Алсу Миссарова, выпускница мехмата МГУ, PhD по системной биологии (functional genomics in yeast) в Universitat Ponepu Fabra в Барселоне. Сейчас Алсу постдок в лабе JOhn Marioni (EBI, Cambridge, UK), занимается single cell RNA-seq and интеграцией со spatial transcriptomics.

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

---

Меня зовут Алсу Миссарова. Меня просили рассказать про биоинформатику в частности, какие задачи я решаю, какого рода данные я обрабатываю, какого рода задачи есть в вычислительной биологии для технарей, для людей с уклоном в computer science, data analysis и так далее.

Я сама не биоинформатик, я computational biologist. Эти два понятия весьма коррелируют, и грань между ними размытая, но важно понимать разницу. И у того, и у другого целью являются ответы на какие-то биологические вопросы, или улучшение нашего понимания того, как устроены биологические процессы. Подход у них схожий: обработка и data analysis большого количества данных, которые глазами-руками нельзя обработать. Разница в приоритете. У Computational biologist скорее будет относительно специфический биологический вопрос, и нужно будет понять, какого рода данные нужно собрать. Нужно иметь доступ к этим данным, нужно уметь правильно обрабатывать, анализировать, интерпретировать и, собственно, отвечать на вопрос. Когда цель информатика, это, скорее, создание алгоритмов, тулов, методов для того, чтобы работать с биологическими данными. Задача будет положена сверху, скорее всего, и данные будут в более промышленном формате. То есть, у них будет определенный формат данных, которые они будут обрабатывать, которые нужно будет производить для большого количества индивидуумов или организмов и так далее.

Можно воспринимать это так: Computational biologist скорее, биолог, который может открывать какие-то библиотеки и использовать какие-то тулы, а биоинформатик скорее, именно компьютерщик, которому до биологии дела нет, который в ней не очень разбирается, и он просто работает с числами, со строками, с данными. На самом деле, это не так, конечно. Это актуально для любой сферы, но, когда вы работаете с данными в любой сфере вам абсолютно необходимо понимать, какого рода у вас данные и откуда у вас шум в данных. И в биологических данных, которые вы будете получать, шума будет очень много. Его можно, грубо говоря, разложить на технический и биологический шум. Технический шум получается из-за того, что машины, которые создают данные, не идеальны и допускают огрехи. А биологический шум возникает потому, что в любой системе очень много вариации. Даже между двумя клетками одного и того же организма, даже если это соседние клетки кожи, будет биологическая разница. Надо отличать технический шум от биологического, убирать технический и оставлять биологический, и для этого нужно понимание биологии.

Перейдем к тому, какого рода данные в биологии у нас есть. В первую очередь, когда люди слушают биоинформатику, они думают про ДНК-секвенирование (что, в принципе, оправдано). Я думаю, все знают, что это такое: это, условно говоря, умение определять, какая именно последовательность ДНК имеется у организма. То есть, ДНК очень длинная молекула; у человека это примерно 3.1 миллиарда букв. 4 буквы АЦДГ это нуклеотиды. Соответственно, люди научились читать ДНК живого существа. Это очень круто. Теперь можно, например, определить последовательности двух людей, сравнить их и сопоставить, в чем разница между этими последовательностями и в чем разница между этими людьми, и попытаться найти причинно-следственную связь. То есть, как ДНК влияет на ваш фенотип, в чем разница между двумя людьми. Так же, допустим, в вычислительной биологии: вы можете взять два организма из соседствующих видов, точно так же их секвенировать определить ДНК-последовательность и, соответственно, попытаться понять, в чем разница между двумя организмами, и что из ДНК на это, собственно, влияет.

Теперь можно пойти в другую размерность и задать такой вопрос: если взять две клетки из одного организма, из одного человека, то в чем между ними разница? То есть, условно говоря, клетки эпителия кожи будут отличаться от нейронов. Тут ДНК уже не очень подходит. Есть такая аксиома, которая по большому счету ошибочна: то, что последовательность ДНК клеток одного организма всегда одна и та же. Она ошибочна потому, что живой организм это динамическая структура; он растет, делится, умирает. В этом процессе накапливаются мутации. Процесс репликации ДНК не идеален, и иногда идут поломки; ДНК повторяется, но повторяется неидеально. Мутации могут быть нейтральные, которые ни к чему не приводят, или вредные, которые вызывают дисфункцию клетки. Конечно, если абстрагироваться, последовательность ДНК все-таки более-менее идентична между двумя клетками, но функционируют они по-разному. Соответственно, большое количество биологических вопросов нацелено на понимание того, в чем разница между различными клетками и что на это влияет. У комьюнити есть запросы на такого рода данные. Нужно уметь выделять, вычислять, считывать эту разницу.

Тут мы подходим к тому, чем я занимаюсь. Основной (или один из основных) формат данных, который люди используют здесь это РНК-секвенирование. Сейчас я коротко расскажу про то, что такое РНК, и про эволюцию РНК-секвенирования в целом.

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

Один из ярких примеров этого белки. Это такие маленькие машинки в клетке, которые выполняют определенные функции и обеспечивают жизнь и функционал этой клетки, чтобы она работала, как нужно. Белки кодируются генами. Ген это подслово в ДНК-последовательности. Транскрипция это когда на длинную двойную спираль молекулы ДНК садится большая молекулярная машина полимераза, которая идет по генам, создает копии и выбрасывает их в цитоплазму клетки. Эти копии ДНК (на самом деле, не совсем копии) создаются в определенном количестве. Соответственно, в двух разных клетках разное количество РНК от разных генов. Для клетки эпителия нужно больше гена А, для нейронов больше гена Б, и их производится разное количество. Дальше РНК процессируется, и потом, когда оно в более конечном формате, на нить садится другая машина. Соответственно, когда люди говорят про РНК-секвенирование, они имеют в виду, условно говоря, вычисление того, сколько каких РНК из каких генов в клетках производится. Это РНК-композиция, или РНК-секвенирование.

На самом деле, очень круто, что люди научились это делать. Долгое время главным ограничением этой технологии было то, что для получения РНК-материала требовалось очень много клеток. То есть, нужно было десятки тысяч клеток сложить вместе (естественно, уже нежизнеспособных), вытащить РНК и секвенировать.

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

И, соответственно, был запрос у комьюнити на то, чтобы это делалось на single cell level. И это научились делать лет 10 назад. Это очень круто, для многих областей это очень актуально. Можно очень глубоко взглянуть в систему, посмотреть, какого рода клетки находятся на микроскопическом уровне. Но там тоже есть ограничения. Одно из них это то, что вы теряете вашу пространственную информацию. Условно говоря, чтобы сделать РНК-секвенирование, вам нужно взять кусок ткани, разрезать на клетки, и делать ваш single cell RNA-seq.

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

Один из основных приемов для этого это использование микроскопа: вы берете вашу ткань, фиксите ее то есть, берете набор клеток, и он у вас зафиксирован в микроскопе. И дальше вы посылаете маленькие probe на эту ткань, которые содержат два элемента: один из них очень специфичен к вашему РНК, и он будет связываться только с теми генами, которые важны. А второй будет светящаяся флуоресцентная марка. Вы можете посветить микроскопом с определенной частотой волны на ткань, и вы можете определить, сколько загорится светлячков в клетках. Соответственно, столько будет РНК-молекул. Собственно, задачи, которыми я занимаюсь, находятся на стыке special transcriptomics и single cell РНК-секвенирования. Условно говоря, вот я занимаюсь development, смотрю на маленьких мышей; у меня есть данные по single cell и special transcriptomics, и я пытаюсь между собой сопоставить клетки, которые вижу в special-контексте, и те, которые я вижу в single cell RNA-seq.

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

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

Тут есть несколько этапов. Один из них это target identification/validation. Надо как-то уметь предсказать, какие молекулы нужно связывать, чтобы состояние болезни изменилось. Для этого собирается большой набор данных: вы берете больных людей, вы берете здоровых людей, вы измеряете очень много разных параметров у них. Вы секвенируете ДНК, РНК, транскриптомику, протеомику состояние белков.

Дальше вы пытаетесь определить, какие из параметров клеток больных людей относятся именно к больным людям, а какие к здоровым людям. То есть, пытаетесь определить, какие молекулы потенциально коррелируют с болезнью. Это с одной стороны. С другой, нужно еще найти такие молекулы, которые будут drugable то есть, которые имеют потенциал связываться с активными химическими веществами, которые вы отправите в организм, чтобы вылечить. Тут надо измерять множество параметров: связываемость, сворачиваемость белков и так далее.

Для этого сейчас используется активный Machine Learning. То есть, вы смотрите на разные белковые соединения и пытаетесь предсказать на основе известных target, будет ли конкретный target хорошим. Кроме того, надо также синтезировать правильный drug. То есть, вам нужно найти такой химический состав молекулы, который сможет связаться специфически именно с тем белком, с которым нужно связаться, а также сможет в принципе попасть в организм, сможет раствориться в воде и так далее. Есть много features, которые нужно оптимизировать. Делать это руками тяжело, но это можно предсказывать на основе того, что у вас уже есть известные drugs, и вы сравниваете новый потенциальный drug с известными и предсказываете, насколько успешным он потенциально может быть. Все это на уровне предсказания; потом это нужно будет валидировать, действительно показать, что это работает. Но drug-ные предсказания это ключ к сокращению траты денег и времени на research. Это очень актуально.

Второй род задачи, связанный с первым это, условно говоря, нахождение биомаркеров болезни. Хороший пример это рак. Отчасти его так тяжело лечить потому, что он очень разный, и бывает много различий между двумя людьми. В целом, что такое рак это когда накопилось какое-то количество мутаций, которое привело к поломке клетки. И клетка вместо того, чтобы выполнять свою функцию, начинает просто очень быстро делиться и замещать здоровые клетки. Это постепенно убивает организм. Но механизмов, из-за которых клетка ломается, очень много. Рак одного человека это не рак другого человека, и лекарство, которое подошло одному, может не подойти другому. Соответственно, очень важно уметь быстро определять то, какие именно гены и другие параметры нужно смотреть, чтобы понимать, что человек болеет конкретным заболеванием. То есть, надо находить биомаркеры. Для этого используются базы данных. Сейчас активно собираются данные разного формата у большого количества людей, здоровых и больных. Нужно кристаллизировать output; человек может вылечиться или не вылечиться, и нужно понять, какие люди чем заболевают. Если вы таргетно найдете быстро, что именно поломалось, то вы сможете это вылечить.

Третье направление, которое сейчас развивается забавно, но это text mining. В биологии сейчас очень много литературы, очень большое количество labs занимаются огромным количеством вещей. На самом деле, люди часто находят вещи допустим, protein-protein interaction или drug-protein interaction. Это происходит независимо, в разных частях света, и они не знают, как это может взаимодействовать. Text mining смотрит на разные статьи, которые публикуются, и создает базу данных. То есть, если в одном месте определили, что один белок взаимодействует со вторым белком, а в другом что на второй белок можно подействовать определенным drug, то получается, что этим drug можно подействовать и на изначальный белок. Создается граф взаимодействия, и вы можете предсказывать новые, ранее ненайденные interactions.

Еще один тип задач, который я хотела упомянуть и который, как мне кажется, достаточно интересен это image analysis. Вообще, image это мощный data-формат, который в биологии очень часто и много используется, потому что по тому, как выглядит клетка, можно многое понять про нее.

Если накапливается большое количество микроскопических картинок, вам нужно их быстро анализировать и уметь делать предсказания. Стандартный пример опять же, рак; вы берете биопсию и смотрите на то, как здоровые и больные клетки соединены. Вы их красите ядро в один цвет, цитоплазму в другой. Дальше вы пытаетесь предсказать: эта ткань с опухолью, или нет?

Для более фундаментального исследования обработка картинки с микроскопа уже сложнее; люди хотят смотреть на определенные органеллы, или молекулы, или на белки, и, соответственно, проследить, как клетки будут взаимодействовать между собой, как развиваться, и так далее. Люди научились подкрашивать разные элементы клетки, и это делается с помощью флуоресцентных белков. Вы берете то, что вам нужно, и присоединяете к этому такой белок с меткой. И если посветить на него светом, то он загорится, и вы поймете, что эти органеллы, или белок, или РНК находятся в определенном месте. И дальше вы отслеживаете, как взаимодействуют клетки. Для этого тоже нужен image analysis, потому что картинок очень много, и они, как правило, не очень хорошего разрешения. И вам нужно из мутных картинок получать хорошее разрешение. На самом деле, комьюнити не стоит на месте; люди пишут нейронные сети, изменяют разные параметры и так далее. Но данные развиваются, и с ними должны развиваться и методы. То есть, эти вещи должны идти нога в ногу.

Актуальное направление, о котором думают многие лабы это как покорить время. То есть, очень часто и в секвенировании, и в image analysis и прочем есть такая проблема: существует snapshot системы, но он статичен. Вы делаете измерение за конкретное время. И вам непонятно, как клетки будут развиваться дальше. Один из подходов к решению этой проблемы это life imaging. Когда вы клетки не убиваете, а помещаете в среду, в которой они развиваются, взаимодействуют и прочее, и микроскопом каждые 10 секунд, каждую минуту делаете snapshot, и дальше можете восстанавливать траектории движения, взаимодействия и так далее. Но тут есть limitation: например, флуоресцентные марки не очень хорошо использовать для life imaging, потому что, когда вы светите вашим светом на марку, она издает излучение, и это токсично для клетки. Клетка начинает умирать. Нужно найти компромисс: с одной стороны, вы хотите оставить клетку как можно более здоровой, но, с другой стороны, вы хотите сделать больше snapshots но, чем больше вы их делаете, тем быстрее она умирает.

И тут есть такой подход: люди пытаются сейчас с помощью минимального количества флуоресцентных марок, а на самом деле только с помощью микроконтура ядра и клетки, определить судьбу клетки. Это как с face recognition: раньше можно было делать его с видимыми глазами, ртом, носом, другими чертами, а сейчас надо делать только с помощью носа, потому что на глазах могут быть солнечные очки, а на рту маска. То есть, проблема усложняется, и тут то же самое. Нужно с помощью малого количества информации вычислять биологические параметры, и тут есть большое количество задач.

Задач очень много, типов данных очень много. Измеряются все параметры клеток, организмов и прочего. Это очень интересная область. Надеюсь, если вы думали про нее раньше, то я вас не разуверила.

---

Что было ранее

1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
18. Как Data Science продает вам рекламу? Интервью с инженером Unity
19. Как я переехал в Лондон c Revolut
20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
21. Наталья Крапкина Как организовать IT-конференцию и не сойти с ума
22. Александр Чистяков Docker уже умер или все, что вы хотели узнать про Devops, но боялись спросить

В ПОНЕДЕЛЬНИК, 9 ноября, в 20:00 в наших соцсетях выступит Алексей Лобзов главный системный аналитик Альфа-Банка, техлид аналитиков корпоративного направления. Алексей занимается подбором, онбордингом и развитием системных аналитиков. Так же, он известен на Хабре как alobzov, регулярно выступает с докладами, обучает системных аналитиков онлайн.

О чем расскажет Алексей, кроме ответов на вопросы

• Развитие сообщества.
• Популяризация профессии.
• Подготовка аналитиков.
• Есть ли сообщества у системных аналитиков.
• Как обменяться опытом на стороне.
• Об организации собственного сообщества.
• Зачем я пишу и рассказываю о системных аналитиках.
• Как на два разработчика стало меньше.
• Откуда приходят в аналитику и куда уходят.
• Возможно ли вырастить системного аналитика с нуля.
• О школе системного анализа Альфа-Банка.
• Об онлайн-обучении.

Кроме того вы можете задать вопрос о системной аналитике здесь в комментариях или в инстаграме и он ответит на них в прямом эфире.

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Недавно на нашем ютуб-канале выступил Алексей Лобзов главный системный аналитик Альфа-Банка, техлид аналитиков корпоративного направления. Алексей занимается подбором, онбордингом и развитием системных аналитиков. Так же, он известен на Хабре как alobzov, регулярно выступает с докладами, обучает системных аналитиков онлайн.

Делимся записью эфира и расшифровкой.

---

Меня зовут Алексей Лобзов, я являюсь главным системным аналитиком в компании Альфа-Банк. Я одновременно выполняю роль технического лидера аналитиков корпоративного направления нашего банка.

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

Есть ли какое-то официальное определение системного аналитика и его области ответственности?

Это роль на проекте, в продукте или компании, или профессия/должность?
Системный аналитик это профессия. На сайте Минтруда есть раздел Справочник профессий, где можно найти профессию системного аналитика и прочитать, в чем состоит ее описание. Также с этой страницы можно перейти на профессиональный стандарт и узнать, какие функции ожидаются от человека этой профессии.

Хотя, на практике могут быть отклонения. Так или иначе, если вы устраиваетесь на работу на должность системного аналитика, то у вас будет должностная инструкция с обязанностями, которые работодатель ожидает от вас. Отклонения от стандарта, скорее всего, не будут существенными.

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

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

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

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

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

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

Это произошло относительно недавно; это было тогда, когда я пришел в Альфа-Банк, в начале 2017 года. Тогда моя команда (и еще 4 таких же команды) занималась созданием интернет-банка для юридических лиц и ИП. Каждая команда развивала свой программный продукт, и интернет-банк в целевой картине должен был состоять из этих продуктов. Мы пришли к пониманию того, что все эти продукты невозможно развивать независимо, каждый по-своему.

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

Я хотел поделиться конкретно с сообществом аналитиков, и передо мной встала задача: найти такое сообщество. Я поспрашивал у коллег из Альфы; мне сказали, что есть популярная конференция аналитиков Analyst Days. Она проходит каждый год, и можно пойти туда и выступить, или хотя бы поучаствовать, узнать какие-то интересности, которые можно будет потом применить в работе.

Я начал анализировать возможность посещения этой конференции и как спикер, и как обычный участник; в итоге я пришел к выводу, что эта конференция мне не подходит. Этому было две причины: во-первых, в моем понимании, на конференцию приходят серьезные люди с серьезными темами, и участники платят за то, чтобы послушать их и задать вопросы. Во-вторых, я просто не был готов платить за билет участника; у меня был пример Московское сообщество разработчиков на Python (Moscow Python Meetup), которое ежемесячно проводит митапы со свободным входом. Там можно бесплатно прийти, послушать спикера, задать вопрос, пообщаться с питонистами, съесть пиццу в пицца-паузе; если у тебя есть тема, то ты можешь самостоятельно записаться, заявить тему перед оргкомитетом, и, если тема подходящая, тебя с высокой вероятностью включат в план выступлений. Поэтому я стал искать что-то похожее на MPP, но для сообщества аналитиков.

Поиск выдал мне информацию о сообществе аналитиков с сайтом uml2.ru. Я ознакомился с сайтом, мне все понравилось; даже попробовал сходить на несколько встреч сообщества. В принципе, было все интересно: контент, люди. Не устраивала меня регулярность встреч: по сравнению с сообществом питонистов эти встречи проходили нерегулярно (или я не получал информацию о том, когда будет очередная встреча). Плюс, с сообществом аналитиков у меня не срослось возможно, были дополнительные факторы. Мне пришлось выступать с докладом у разработчиков на Python.

Время шло; потребность в сообществе осознал не только я, но и мои коллеги из Альфы. В 2018 году родилась внутренняя инициатива: создать собственные митапы для аналитиков.

Мы собрались с коллегами и создали митап AnalyzeIT: первый раз он прошел 20 сентября 2018 года. В 2019 году было еще два митапа, мы планировали проводить их раз в полгода. В том же году прошел митап от сообщества аналитиков Райффайзенбанка я узнал о нем от коллег из Райфа, которые предложили мне поучаствовать в качестве докладчика. Я не мог отказать; таким образом, я узнал про новое сообщество системных аналитиков, которое мне подходило. Со временем, с моим ростом, с приобретением новых знаний, с общением внутри сообществ я стал узнавать о новых и новых площадках, на которых можно было обмениваться опытом, заводить контакты, организовывать проекты, даже искать новую работу. Из таких площадок я могу выделить Открытый митап для аналитиков: он проходит онлайн, недавно прошла первая встреча, и следующая планируется на 26 ноября. Его идея состоит в том, что, на самом деле, сообществ аналитиков по России очень много; если брать региональную разбивку они есть в Москве, Петербурге, Екатеринбурге, Перми, других городах, и требовалась площадка, на которой люди из разных сообществ могли бы коммуницировать друг с другом.

Как я уже сказал, 26 ноября будет вторая встреча этого сообщества IT Analyst Online Meetup. Если вам интересно зарегистрируйтесь; думаю, она пройдет полезно.

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

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

Я рассказал, что есть несколько митапов для аналитиков, где можно свободно выступить, задать вопрос спикеру, пообщаться с членами сообщества. Помимо митапов, есть и другие площадки; сейчас очень популярны телеграм-группы: у того же Райффайзенбанка есть группа для системных аналитиков, я в ней состою. Там, хотя и не так часто, появляются вопросы, и сообщество с удовольствием предлагает варианты решения проблем. Группа называется Open SA Community Raiff; если вам интересно, тоже заходите. Как пример вопроса: недавно заходила девушка и писала, что работает в системном анализе, но чувствует, что в знаниях не хватает структуры, общей методологии аналитика. Она спрашивала мнения сообщества о том, как получить такую структуру; с одной стороны, можно пойти получить высшее образование, с другой сейчас есть много онлайн-курсов, в том числе и по системному анализу, и, возможно, стоит идти туда. А, возможно, стоит попросить руководителя или лида побыть ментором и помочь прокачать аналитику. Различные варианты, возможности; в сообществе как раз и обсудили, что может быть лучшим вариантом.

На митапах можно найти работу джуном?

Да, на митапах можно найти работу. Если мы берем митапы от Альфа-банка там всегда есть HR-специалисты, у них можно получить информацию по вакансиям и передать им свое резюме для рассмотрения. Если в компании есть джуниорские позиции, то можно на них претендовать. Сейчас в Альфе есть оплачиваемые стажировки; конечно, их немного, но они доступны если бы сейчас проводились митапы, можно было бы на них претендовать. Я думаю, на любом митапе, где присутствуют представители HR компании-организатора, есть шанс найти джуниорскую позицию. Поэтому, ходя по митапам, нужно спрашивать.

Я упомянул телеграм-группу Райффайзенбанка; на самом деле, есть и другие группы. В том числе, можно найти отдельные группы по городам. Недавно на Хабре я видел статью, которую написала Анна Михайлова из консорциума Кодекс статья посвящена теме развития аналитиков. Она упоминала сообщества, приводила ссылки на них; в комментариях читатели накидали других ссылок, на телеграм-группы разных сообществ. Статья называется Развитие аналитиков. Ссылок там очень много; все вряд ли можно перечислить.

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

Чем бизнес-аналитик отличается от системного?

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

Если кратко бизнес-аналитик больше работает с бизнес-составляющей. Это работа с бизнес-требованиями, создание процессов, реинжиниринг существующих процессов. Больше процессов и бизнеса. Системный аналитик больше работает с техникой: проектирование архитектуры будущей системы, проектных решений, написание технических спецификаций, плотное взаимодействие с командой разработки. В моем понимании, бизнес-аналитик больше взаимодействует с бизнесом, а системный с командой разработки. Более формальная граница проводится в профессиональных стандартах. Но, так или иначе, от компании к компании обязанности будут отличаться, и это остается спорным вопросом.

Используется ли вы EPС, или достаточно UML и BPMN?

Если мы говорим про то подразделение, в котором работаю я, то в архитектурных и технических документах мы используем все эти нотации. UML Sequence наверно, наиболее популярные. EPC мы используем в архитектурных документах, при описании функциональных моделей процессов. BPMN я лично еще не использовал его, но некоторые коллеги в Альфе используют в описании архитектурных документов.

Если аналитик ищет в enum переменные на C# и сопоставляет их с документацией это не слишком ли большой отход от обязанностей системного аналитика?

Если таково требование работодателя я думаю, это отход от обязанностей системного аналитика. Если это ваша собственная инициатива, то тем самым вы показываете, что вам интересно то, чем вы занимаетесь; вы развиваетесь, вы хотите лучше понимать, что делают ваши коллеги по команде например, .NET-разработчики. В таком случае это ваше преимущество. То есть, если аналитик разбирается в коде, то это должно быть по его собственной инициативе, а не по требованию сверху. Это на мой взгляд.

Могу сказать, что в Альфе многие аналитики погружаются в код, и даже в ходе анализа кода находят логические ошибки, которые не всегда устраняются на этапе ревью со стороны разработчиков. Например, у нас есть единый сервис, определяющий тип клиента банка. Был написан код, который разделяет организации и индивидуальных предпринимателей, и там был прописан анализ ИНН (12 символов ИП, 10 символов организация). Но зачем писать собственную логику, если есть готовый сервис, и все системы банка используют его это единая точка входа. Если у нас логика как-то меняется, то мы вносим изменения в этот сервис. Если есть альтернативные реализации, то мы должны о них знать и в случае изменения менять код не в одном месте, а в двух. Поэтому, если аналитик погружается в код, то он может выявить неточности в логике работы и помочь их устранить своевременно.

Что лучше использовать для верхнеуровневого проектирования системы? Компонентную диаграмму или диаграмму deployment?

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

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

Что, если вы просмотрели множество сообществ, но не нашли ничего для себя? Вам все еще хочется поделиться информацией с другими или узнать, чем занимаются коллеги из других профессиональных сообществ. В этом случае вы свободны в выборе сообщества из другой области. Например, вы можете посетить сообщество разработчиков, посмотреть, чем они занимаются. Или сообщество тестировщиков, или QA-инженеров и обменяться опытом там. Я достаточно долго ходил на митапы сообщества питонистов, мне было там интересно; я даже задумывался о том, чтобы стать разработчиком на Python. Также я участвовал в старте сообщества QA-инженеров компании Додо Пицца. Это было в 2018 году; ребята только начинали свои митапы, прошел один митап и готовился второй в феврале. Они искали спикеров и предложили мне выступить с докладом несмотря на то, что я не являюсь QA-инженером и отношение к тестированию имею опосредованное, только с точки зрения аналитика.

В случае, если вас приглашают в другое сообщество, или у вас есть желание посетить другое сообщество не стесняйтесь, посещайте, выступайте. Мы все работаем в IT, у нас много точек соприкосновения и общих тем для общения. Например, на втором митапе от Додо Пиццы я выступил с докладом, рассказал, как я (как аналитик) участвую в процессе QA, рассказал о техниках, которые аналитики применяют в своей работе, о тестировочных техниках. Должен заметить, что в наших командах приветствуется развитие Т-компетенций. Это когда у тебя есть основная компетенция (у меня системная аналитика) и смежная компетенция (разработка, тестирование). Это помогает лучше понимать, чем занимаются коллеги, и иногда подстраховывать их в выполнении простых задач, если они отсутствуют. То есть, можно прокачать компетенции и, например, разработать несколько автотестов с использованием существующего фреймворка. Поэтому, если у вас есть возможность и желание посещать другие сообщества я очень рекомендую это делать.

Также я хотел упомянуть об организации собственного сообщества. В чем проблема: вы можете пройтись по существующим сообществам, посмотреть сообщества смежных направлений, но вас ничего не устроит; вы видите для себя определенную нишу и готовы запустить собственное сообщество. Если у вас такая ситуация это хороший опыт; вы можете попробовать войти в эту историю и, возможно, из этого что-то вырастет. На примере Альфы как я уже говорил, мы запускали собственное сообщество, свои митапы AnalyzeIT. У нас было всего три митапа. Как мы их запускали: у нас была команда аналитиков, которые отвечали за контент, и команда из отдела развития бренда, которая отвечала за организацию помещения, привлечения участников и слушателей и за организацию бургер-пати (потому что какой митап без бургер- или пицца-пати; очень важный компонент можно перекусить и пообщаться с коллегами, которые пришли на мероприятие). Организация первого митапа потребовала много времени; мы тщательно готовились, отобрали несколько докладов и 3-4 недели проводили их репетиции. Была безумная подготовка, потом выступили и выдохнули. Остальные митапы были полегче, потому что мы получили опыт, но первый был самым сложным и запоминающимся.

Конечно, сейчас митапы не проводятся из-за эпидемии; в онлайн мы ещё не вышли, но следующем году, возможно, будет развитие.

Мне очень понравилось участвовать в организации сообщества системных аналитиков от Альфа-банка, и в качестве спикера в старте сообщества аналитиков от Райффайзенбанка, и в организации митапов для QA-специалистов от Додо Пицца. Все это полезный опыт.
Я хочу перейти к следующей теме популяризации профессии. Я, как системный аналитик, хотел бы популяризовать нашу профессию. Зачем это нужно? Я выделил для себя две главных причины того, почему стоит этим заниматься.

Первая из них состоит в том, что до сих пор ощущается острое непонимание рядом специалистов сути того, чем все-таки занимаются аналитики. Оно возникает по нескольким причинам. Во-первых, в разных компаниях под должностью аналитика подразумевает различные вещи не кардинально, но различия есть.

В одних компаниях аналитики занимаются только работой с требованиями и написанием верхнего уровня в их ТЗ, в других они лезут в БД, делают запросы и пишут хранимые процедуры.

Все относительно и зависит от самой компании. Если она может позволить себе иметь выделенную должность техписателя, то аналитик будет заниматься работой с требованиями и проектирование, а не описанием существующих решений и документированием системы. В разных компаниях разные требования и ожидания для аналитика, поэтому порой возникает непонимание: чем должен заниматься эталонный аналитик?

Если читать интернет-ресурсы тот же самый Хабр то можно найти относительно много публикаций на одну и ту же тему: какие типы аналитиков бывают и чем они отличаются. Я видел такие публикации и в 2013 году, и сейчас. Вроде бы прошло 7 лет, но об этом продолжают писать значит, непонимание сохраняется.

Например, статей о том, какие типа разработчиков на Python бывают и чем они отличаются, нет; понятно, что среди них есть такие, кто занимается разработкой софта, или аналитикой данных с использованием Python для анализа, но статей с разделением их на типы я не встречал. Наверно, с этой специальностью-профессией все понятно, а вот с аналитиками нет.

Собственно, поэтому я хожу и рассказывают о наших аналитиках. У меня есть опыт системного анализа в Альфа-Банке, и поэтому я фокусируюсь на том, кто же такой системный аналитик в Альфе, чем мы живем, чем занимаемся, как пишем документацию, как оцениваем ее качество, работаем ли мы с метриками продуктов, как происходит развитие наших аналитиков. Я пишу обо всем этом, но с примечанием, что это происходит именно в Альфе; какую-то обобщенную точку зрения на то, кто такой системный аналитик, я не могу дать для этого лучше воспользоваться профессиональными стандартами. В них написан эталон.

Очень интересный кейс, связанный с популяризацией профессии я его назвал кейсом о том, как на двух разработчиков стало меньше. У меня есть два знакомых девушка и парень; девушка закончила технический университет и искала место для стажировки, парень имел большой опыт работы, последние несколько лет работал в продажах, но хотел сменить деятельность перейти в ИТ.

То есть, оба искали возможности в ИТ-сфере; конечно, первое, что приходит на ум в связи с ИТ это программирование, поэтому они смотрели, в том числе, на то, могут ли они зайти на рынок разработчиков информационных систем, и, если могут, то куда: front, middle. У них были свои предпочтения и обстоятельства. И ребята, на самом деле, не до конца понимали, чем занимается системный аналитик; но после того, как мы с ними побеседовали, у них появился интерес. Вслед за беседой я привел их на второй митап от Альфы, они пообщались с нашими аналитиками, послушали доклады. Девушка потом устроилась на стажерскую программу в Альфа-банке, прошла ее и теперь работает в одном из подразделений системным аналитиком. Парень прошел через школу системного анализа, тоже у нас, устроился в штат и сейчас работает в другом подразделении.

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

Следующий поинт откуда приходят в аналитику и куда уходят из неё; это пересекается с одним из вопросов из зала: какая следующая ступень после системного аналитика.

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

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

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

Куда системные аналитики уходят дальше? Если брать модель Альфы, то можно выделить бизнесовое и техническое направление. Бизнесовое направление это развитие в сторону владельца продукта; будучи аналитиком, ты развивался как член команды разработки, но теперь ты хочешь выйти из команды разработки, взять ответственность за продукт на себя, хочешь, чтобы тебе выделили бюджет, на который ты бы собрал собственную команду разработки и занялся бы развитием интересующего тебя продукта. Техническое направление это путь к становлению solution-архитектора. Кто это такой? Если взять за пример интернет-банк для юридических лиц, то, с точки зрения клиента, этот банк большая единая система; но с точки зрения нас (как команд разработки) он совокупность программных продуктов, развитием которых занимаются разные команды. Есть команды, которые занимаются развитием приложений по рублевыми платежам, или по депозитам, или по другим направлениям. Много приложений и много команд. Аналитик у нас во-первых, член команды разработки, и, во-вторых, позиционируется как архитектор в рамках своего программного продукта. Solution-архитектор отвечает за архитектуру всего интернет-банка в целом, работая в более широком контексте, чем аналитик. Аналитик эксперт в своем продукте, а архитектор должен разбираться во всем банке. Это второй путь развития аналитика.
Естественно, не забываем про организационную структуру. Если у вас есть возможность, то можно после рядового аналитика или аналитика высокого уровня можно стать руководителем направления, руководителем центра компетенции системной аналитики и далее руководителем дирекции и так далее, как позволит структура.

Чем отличается старший аналитик от ведущего?

Отличается рядом факторов. В разных компаниях требования к старшему и ведущему аналитикам различаются, но глобально различия включают в себя опыт работы, ряд технических навыков, которые он продемонстрировал в ходе выполнения задач, и набор дополнительных обязанностей, которые аналитик выполняет в дополнение к работе над проектом. Это могут быть обязанности по проведению технических интервью, например: опытный аналитик может общаться с кандидатами и давать взвешенную оценку их скиллов аналитики. Если мы считаем, что он способен это делать, то он явно выше, чем обычный старший аналитик. Или он может отвечать за дополнительный блок работ. В общем, у него обычно больше обязанностей соответственно его более высокой компетенции. Но от компании к компании требования, которые разграничивают одного аналитика от другого, различаются.

Расскажите про микросервисную архитектуру

Да, в Альфе используется микросервисная архитектура. У нас есть как монолитные, так и микросервисные системы. Мы идем в микросервис.

Третий блок моего выступления относится к подготовке аналитиков, в первую очередь к подготовке аналитиков с нуля, или подготовке людей, которые еще не имеют определенного опыта в профессии.

У нас одно время была потребность в новых специалистах: банк рос, наше подразделение росло. В какой-то момент мы столкнулись с осознанием проблемы: на рынке не хватало людей, которые удовлетворяли бы нашим критерием. Эта проблема возникла потому, что мы в те времена пользовались, в основном, нашим локальным рынком то есть, рынком тех городов, где у нас находятся офисы (например, Москва и Санкт-Петербург). То есть, большую часть ребят мы тогда смотрели именно в этих городах и не шли в регионы.

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

Мы провели пилот в 2018 году; я познакомился с первым кандидатом мне предложили провести онбординг. Девушку посадили в мою команду на период испытательного срока; идея состояла в том, чтобы, работая в команде и взаимодействуя с опытными аналитиками, она бы приобрела необходимые знания для джуна и потом уже, в ходе работы, развилась бы в серьезного аналитика. По результатам 3 месяцев девушка показала достаточно неплохой результат; по ее отзыву, она бы прошла план, который мы составили на 3 месяца, за 2 недели, если бы была опытным аналитиком: то есть, у нее уже возникло осознание того, какие навыки и знания она приобрела за это время.

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

СОА или монолит?

Могу сказать, что в банке много разнообразных систем. Если вы работали в банке или сталкивались с похожими системами, то вы представляете, сколько их может быть. У нас есть и СОА, и монолиты, и микросервисы полный набор.

Как эффективно найти работу начинающему системному аналитику?

Много факторов влияет на успех в поисках работы. Немалое значение имеет желание самого кандидата найти эту работу и развиться в области. Бывает так, что человек приходит на курсы, говорит: научите меня. Заканчивает его, получает сертификат, потом ходит по собеседованиям и показывает его. Но если при этом у него нет желания, нет огня в глазах тогда поиск будет затруднительным.

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

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

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

На что смотрят при приеме джуна на работу, какой минимум нужен?

Вопрос непростой, потому что до недавнего времени в Альфе начальная позиция называлась старший системный аналитик. Она подразумевала, что в центр компетенции приходит не джун, а опытный специалист с определенным набором знаний и умений. Просто джунов мы не брали. Были стажерские программы (я уже рассказывал про свою знакомую); там было собеседование и задачи в частности, на SQL. Я думаю, если вы ищете джуниорскую работу, то надо почитать, что обычно спрашивают на джуниорские позиции. Моей знакомой знаний из института и предварительной подготовки по SQL оказалось достаточно.

На более высокие позиции, на которые собеседую я, мы не рассматривали джунов до недавнего времени; джуны скорее приравнивались к стажерам.

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

С моей точки зрения, беря опыт моего текущего места работы, для системного аналитика можно выделить 3 области работы. Проектирование информационных систем, документирование разработанного и разбор боевых ошибок. Если мы говорим про проектирование, то результат архитектурное решение плюс спецификации на разработку. Для документирования документация по слоям приложения (фронт, мидл, бэк); часто документация и спецификация пересекаются то есть, иногда это один документ. Если мы говорим про разбор дефектов мы, как продуктовая команда, работаем на качество и заинтересованы в том, чтобы наш программный продукт не имел дефектов. Мы стараемся устранить их. Аналитик, в том числе участвует в разрешении дефектов прода.

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

На самом деле, я буду рекомендовать своего работодателя. Команд у нас много, они разные, везде есть свои особенности. Но именно тот процесс, который у нас построен, меня привлекает.
В чем состоит эта особенность?

У нас системный аналитик рассматривается как мини-архитектор.Он занимается проектированием архитектуры, и это больше технический специалист. Мы в меньшей степени работаем с бизнес-требованиями, созданием или реорганизацией бизнес-процессов. Здесь вопрос на любителя: если вам нравится общаться с заказчиком, разбираться в нюансах бизнеса, вы не хотите соприкасаться с техникой, то мое подразделение вам не подойдет.

Если же вам нравится погружаться в технику, если у вас есть интерес и вы готовы читать код, учиться писать автотесты для того, чтобы понимать, как работают ваши QA-инженеры и при случае помогать им, то Альфа подойдет вам. Иначе можно посмотреть другие компании. По отзывам, в Лаборатории Касперского хорошо устроены процессы системного анализа; в Райффайзенбанке тоже есть интересные задачи для аналитиков. Это спорный вопрос, конечно: компании большие, команд много, в каких-то командах может быть хорошо, в других плохо. У меня есть знакомая, которая занимается биометрией в Сбере она гордится своей командой, говорит они на высоте, они лучшие. А другие люди приходят к нам из того же Сбера и говорят, что работа скучная, релизы редкие, доступов приходится ждать месяцами. Раз на раз не приходится.

Я назвал несколько компаний; на мой взгляд, там, наверно, хорошо быть системным аналитиком. Как будет в реальности, я не могу гарантировать на это влияет много факторов.

Для джунов главное хардскиллы, что бы вы конкретно рекомендовали?

Да, для джунов главное хардскиллы, чтобы в первое время выполнять относительно рутинную работу. Я бы порекомендовал научиться структурно писать документы, разобраться в типах сервисов и в написании постановок для них, из чего они состоят. Вначале у джуна будет основной поток задач связан с тем, чтобы описать, как реализована система, либо написать постановку по известным требованиям: что нужно сделать, что запрограммировать, чтобы получить техническое решение. На собеседованиях у нас спрашивают знания SQL, но навыки проектирования структур данных и информационных систем настолько же важны (или важнее); если вы это знаете, хорошо разбираетесь и умеете это описывать, то, наверно, это будет ваш плюс.

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

Я бы порекомендовал, во-первых, посмотреть, что предлагают компании. Некоторые компании предлагают школы подготовки аналитиков с нуля, даже не из ИТ я рассказывал, как это было в Альфе; знакомый продажник пришел, и его подготовили. Есть онлайн-курсы, в том же самом GeekBrains (факультет системной бизнес-аналитики), SkillFactory (курс для системных аналитиков я автор этого курса и веду его) или SkillBox (курс для системных аналитиков с нуля). Есть еще Школа системного анализа это серьезный проект, он стартовал в 2011 году и до сих пор существует. Можно найти курсы, можно получить образование. Здесь есть разные варианты: можно сначала поучиться, можно получить некий опыт а онлайн-курсы позволяют выполнять кейсы и набивать портфолио и после этого пытаться устроиться по профессии.

Я рассказал, что был опыт подготовки системного аналитика с нуля это реально. Мы запускали в Альфе школу, нацеленную на то, чтобы массово готовить новых аналитиков; наш пилот закончился успехом, по результатам проведения школы у нас появились аналитики, которых мы взяли на работу. У нас было 18 учеников, которые прошли все этапы отбора. 6 из них устроились у нас в штате, то есть треть; еще один человек получил повышение в своей компании за счет новых навыков и знаний. Поэтому эта школа принесла свои плоды, и большинство ребят, пришедших в нее, не имело опыта в ИТ или смежной профессии.

Я назвал три площадки для онлайн-курсов: GeekBrains, SkillFactory, SkillBox. Я, конечно, могу порекомендовать SkillFactory, потому что являюсь автором и ведущим одного из курсов, но это было бы нечестно с моей стороны; площадок много, я до конца не знаю, что происходит на других площадках и как на них организован учебный процесс. На мой взгляд, у GeekBrains очень большая программа; если посмотреть на сайт, ребята предлагают, в том числе, обучение анализу данных и работе на Python. Я не до конца понимаю, зачем это нужно системному аналитику. На SkillBox неплохая программа, но, судя по косвенным признакам, они больше ориентированы на подготовку именно бизнес-аналитиков; если посмотреть URL-адрес ресурса с описанием системного аналитика, там написано business. Поэтому у меня есть вопросы относительно технической составляющей этого курса, но это только мое предположение; не могу сказать, хорошо ли там или плохо.

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

---

Что было ранее

1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
18. Как Data Science продает вам рекламу? Интервью с инженером Unity
19. Как я переехал в Лондон c Revolut
20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
21. Как организовать IT-конференцию и не сойти с ума
22. Чем биоинформатика отличается от вычислительной биологии краткое введение

Мы продолжаем раскрывать тему биоинформатики как науки из первых рук.

Завтра, 15 октября, в 20:00 в наших соцсетях выступит Ольга Кунявская, младший научный сотрудник лаборатории Центр биоинформатики и алгоритмической биотехнологии СПбГУ.

Оля в науке уже 4 года и сейчас учится на втором курсе магистратуры НИУ ВШЭ Санкт-Петербург по направлению Software Engineering. Закончила Академический университет по направлению биоинформатика.

О чем расскажет Оля, кроме ответов на вопросы

• Как я начала заниматься биоинформатикой.
• Лаборатория биоинформатики в СПБГУ: специфика работы, кто работает
• Spades: программа нашей лаборатории, которая собирает геном
• Моя работа со Spades: оптимизация и поддержка кода
• Проект Nerpa про антибиотики и нерибосомные пептиды
• Что такое нерибосомные пептиды и почему даже микробиологи часто о них не слышали
  
• Маленькая история успеха: предсказали какая бактерия производит конкретный NRP и биологи из Сан-Диего смогли это подтвердить
• Почему в 2000-х годах геном человека был собран неполностью
• Что такое центромеры, почему это сложный участок в геноме для сбора и обработки
• Как мы в СПБГУ изучаем эволюцию центромер
• Почему в биоинформатике как науке много творчества и почему нельзя забывать все, что рассказывали в школе
• Где брать интересные и понятные статьи про биоинформатику и как их читать
• Как попасть в лабораторию при СПБГУ: обучение, минимальные знания, контекст

Кроме того вы можете задать вопрос Оле здесь в комментариях или в инстаграме и он ответит на них в прямом эфире.

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Недавно на нашем ютуб-канале выступила Ольга Кунявская, младший научный сотрудник лаборатории Центр биоинформатики и алгоритмической биотехнологии СПбГУ.
Оля в науке уже 4 года и сейчас учится на втором курсе магистратуры НИУ ВШЭ Санкт-Петербург по направлению Software Engineering. Закончила Академический университет по направлению биоинформатика.

Делимся записью эфира и расшифровкой.

Меня зовут Ольга Кунявская, я работаю в лаборатории, которая называется Центр биоинформатики и алгоритмической биотехнологии. Сначала я расскажу предысторию того, как я попала в биоинформатику, какой у меня был бэкграунд; потом расскажу общие факты про нашу лабораторию, а потом расскажу про три проекта, которыми я сейчас занимаюсь.
Я из Москвы, родилась и выросла Москве. Начала учить программирование в 8 классе, в школе активно занималась олимпиадами, в том числе в 11 классе стала призером Всероссийской олимпиады по информатике. После этого я поступила в Академический университет Санкт-Петербурга; мне кажется, это было правильным решением. Там была сильная программа по математике и программированию, и мне очень нравилось учиться. Я действительно много училась; была тем безумным человеком, который делал домашки в тот же день, когда их выдают, и получает все зачеты до зачетной недели. У нас реально классное образование.

Хотя в школе все было иначе; я была достаточно хорошо подкована в алгоритмах и математике, но у меня была тройка по биологии, английский язык в 10 классе примерно на уровне elementary (после 11 pre-intermediate), и у меня в принципе не получалось писать связные тексты и выражать свои мысли. И еще я дислексик, читаю примерно в два раза медленнее, чем среднестатистический человек; когда я пишу, у меня в абзаце текста обычно бывает куча ошибок за диктанты мне обычно ставили двойку после прочтения первого абзаца. По окончанию школы у меня были не слишком развиты soft skills просто потому, что в школе они не особо требуются, чтобы продвигаться. Умеешь решать задачи хорошо, ты занимаешь высокие места, поступаешь в университет, который хочешь, и soft skills, чтобы чего-то достичь, не нужны.

С этим багажом я в какой-то момент начала заниматься биоинформатикой, на втором курсе университета. К третьему курсу нам требуется выбрать направление, до этого идет общий трек. В университете я многим интересовалась, у меня была радость от того, что я понимаю различные вещи, что у предметов, которые мне нравятся, есть крутые преподаватели. На втором курсе ко мне даже подходил куратор и спрашивал, чем я хочу заниматься: обычно было понятно, каким направлением интересуется человек, но я будто бы интересовалась всем сразу, мне все нравилось, и я везде хорошо успевала. Я решила взять какой-то проект, чтобы попробовать разобраться в том, чем я хочу заниматься. Было много направлений, из которых я не могла сделать выбор. Была теоретическая информатика, которая мне очень нравилась; разработка ПО, языки программирования, какие-то другие направления и биоинформатика. Я решила пойти от противного: вроде бы биоинформатика это, должно быть, то, чем я точно не хочу заниматься из-за приставки био, и именно по ней я взяла проект чтобы понять, что мне это точно не нравится, и спокойно перейти к чему-то еще.

Я даже помню, как я пришла получать проект. Я пришла, сказала, что хочу попробовать проект из этой темы, что я могу кодить и знаю алгоритмы, но не знаю биологию. Мне сказали: да, есть проект, который можно попробовать, и спросили: знаешь центральную догму молекулярной биологии? Я ее, конечно, не знала. Мой будущий научный руководитель (который сейчас мой коллега) сказал: хорошо, вот у нас есть ДНК, что мы из неё получаем? Я: РНК. Он: правильно, а из РНК мы что получаем? Я: не знаю. Он: ну, белки получаем сейчас все расскажу, там все просто.

В общем, не поняла я тогда, что биоинформатика мне не нравится. Это было 4 или 5 лет назад, и за это время многое изменилось. У меня откуда-то взялась тяга к знаниям по биологии хотя я до этого никогда не учила ее специально. Может быть, потому, что я теперь в этом постоянно нахожусь. И английский я выучила.

Q: Что значит: читаю в два раза медленнее, чем другие? Научные тексты нагружены информацией, и часто для понимания их приходится перечитывать несколько раз. Это же не приключенческие романы.

А я приключенческие романы в два раза медленнее читаю. То есть, если дать обычный текст обычному человеку и мне, то я прочитаю в два раза медленнее, еще и вероятностно. Знакомые слова я хорошо читаю, а незнакомые приходится угадывать. У меня есть какое-то видение: наверное, вот там такое слово. Я могу подробнее рассказать про дислексию, если интересно; в целом, это такое нарушение, когда человек воспринимает мир немного по-другому и видит его скорее картинками, поэтому возникают сложности с чтением и письмом, возникают специфические ошибки (например, иногда получаются перевернутые буквы). Представьте, что иногда буквы переставляются, или как-то взлетают поэтому читать тяжело.

Теперь про лабораторию. Я по тому же проекту, который взяла, защитила диплом. В какой-то момент сходила на стажировку в лабораторию летом, пока училась, и, как только университет закончила, устроилась на работу в нашу лабораторию в СПБГУ, где сейчас и работаю. Это мое первое, единственное и неповторимое место работы, все это время я занимаюсь биоинформатикой.

Лаборатория достаточно маленькая, в ней около 15 человек. Хочу сразу отметить, что я в лаборатории сейчас самая младшая и по возрасту, и по времени работы в этой лаборатории, и по времени работы в сфере биоинформатики меня окружают гораздо более опытные коллеги. Я сейчас младший научный сотрудник, так что я пока не являюсь каким-либо крупным авторитетом в нашей области.
(только что мне написали коллеги, что у нас недавно появилась одна новая сотрудница, которая еще младше меня)

Лаборатория появилась в СПБАУ в 2010 году. Поскольку это было до того, как я начала заниматься биоинформатикой, для меня это равносильно тому, как если бы она существовала всегда. Потом она переехала в СПБГУ уже давно, я не помню когда именно и при мне она всегда была там.

Q: Моё восхищение. А сколько вам лет? Возможно, я прослушал

Мне 24 года. Я такая старая, потому что, с одной стороны, я учусь на шестом курсе, а с другой я в третьем классе оставалась на второй год. Со школой вообще сложная история кроме этого, у меня в 9-м классе была неаттестация по английскому языку. И еще я после бакалавриата пропускала год; сейчас я должна была бы уже выпуститься из университета, но еще учусь на шестом курсе. Ну, я не расстраиваюсь.

Основал нашу лабораторию Павел Певзнер достаточно крупный ученый, у него много научных статей; он придумал прорывной алгоритм сборки генома, использующий графы Де Брюина, это было важное открытие. Я еще расскажу про Павла и про работу с ним дальше, когда перейду к центральному проекту, в котором я работаю.
У нас небольшой коллектив в основном, парни лет 30-ти, которые защитили кандидатскую, или находятся в процессе защиты. Почти все сотрудники имеют программистский или математический бэкграунд; есть также и физики, а одна коллега закончила медицинский.

Q: как относитесь к популяризатору и биоинформатику же Александру Панчину?

Нормально отношусь. Я читала его книги по биоинформатике, они мне понравились; я вообще люблю научно-популярную литературу, ничего против нее не имею. Мне кажется, он толково пишет.

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

Перейду к проектам, которыми я занимаюсь. Сейчас их три, и они очень разные. Я занимаюсь ими вместе с разными людьми, и у всех у них разная специфика и предметная область. Поэтому, в целом, из них можно получить общее представление о том, чем у нас в лаборатории занимаются хотя и не полное. Я начну со SPAdes это интересная, специфическая вещь.
Это крупный проект нашей лаборатории. Он написан на плюсах, там достаточно много сложного кода с большим уровнем абстракции, темплейтов и прочего. Ему уже около 10 лет, и этим продуктом активно пользуются он действительно востребован. Он представляет из себя геномный сборщик; я расскажу, что это такое.

Давайте считать, что геном это очень длинная строка, составленная из 4 букв. Мы хотим получить её целиком, но изначально она у нас есть в виде мелких подстрок. Их очень много, в них встречаются ошибки. Сборкой единой строки и занимается геномный сборщик. Обычно Павел Певзнер во время рассказа про SPAdes использует метафору про газеты; я ее слышала уже слишком много раз, но вот: пусть у нас будет куча копий какого-нибудь одного выпуска газеты. Эту кучу вдруг разорвало на огромное количество маленьких обрывков, и теперь нам надо восстановить единственную и неповторимую изначальную копию, чтобы узнать, что там было написано.

Для меня этот проект про разработку; то есть, мне биологическую легенду даже знать необязательно. Это большой проект, и я не разрабатываю основные алгоритмы SPAdes. SPAdes уже написан, и у него есть куча подпроектов, ответвлений: metaSPAdes собирает метагеномы, plasmidSPAdes собирает плазмиды, coronaSPAdes (по-моему, неофициальное название) собирает, как ни странно, ретровирусы (могу пояснить, что такое ретровирусы). Есть сотрудники, которые в этих алгоритмах разбираются, работают с ними, понимают, в чем их специфика, знают, как их собирать, разрабатывают их. Моя задача в проекте непосредственная оптимизация: поскольку SPAdes очень популярен, им много кто пользуется, и ему приходится работать с очень большими данными, его надо очень круто оптимизировать. Истории типа а давайте хранить в этой структуре не int64, а в случае, если в графе мало ребер и их количество помещается в int32, хранить int32. Алгоритмы тут тоже есть, но они связаны не с биологией, а с тем, как лучше все оптимизировать, как сделать такой код, чтобы программа занимала меньше памяти, работала быстрее, была лучше распараллелена. В мои задачи в этом проекте еще входит тестирование, поддержка кода; хотя именно сейчас я не очень много времени уделяю этому проекту. Если, например, пользователь пишет, что в каком-то случае что-то не запускается, то надо сидеть и разбираться, что пошло не так и как этот баг исправить. Разработка разработкой. Один из моих руководителей (у меня четыре разных руководителя) занимается этим проектом гораздо более плотно, каждую неделю делает много патчей.

На самом деле, разработка в этом проекте подразумевает некоторые тонкости. У меня есть много друзей-программистов, и, когда я с ними общаюсь, я часто слышу фразы типа ой, программа столько работает 30 секунд, ее невозможно дебажить, надоело. Когда я начала работать над этим проектом, оказалось, что по меркам биоинформатиков быстрая обработка данных (для маленьких наборов тестовых данных например, мне рекомендовали использовать маленький геном кишечной палочки) это 10 минут. Особенно сложно, когда тестируешь на кластере, потому что к этим 10 минутам еще и добавляется очередь непонятно, когда твой код запустится. Конечно, есть OpenMPI для локальной эмуляции кластера, но иногда на локальном кластере может работать, а на реальном падать, и тогда надо разбираться, почему. Я уточняла у моих коллег, как они с этим живут; мне рассказывали мудрую мысль: думать, прежде чем запускать (много думать, много читать логику, понимать, что пойдет не так, исправлять, потом запускать). Здесь еще спасают логи, потому что у SPAdes очень хорошее логирование всего; это очень важно: когда мы сами пишем программу, нам нужно смотреть на логи в случае падения и восстанавливать, в чем была ошибка, без перезапуска. А еще мы должны уметь понимать по присланным логам, что именно упало у пользователя при том, что пользователь мог обрабатывать очень большие данные, и программа могла упасть после недели работы (такое бывает при работе с метагеномами).

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

Еще одна важная вещь мультизадачность. Мои коллеги реально умеют переключать контекст; я не понимаю, как они это делают. Они могут дописать код, запустить программу на 10 минут, эти 10 минут заниматься совершенно другим делом (переводить диссертацию, читать статьи, отвечать на письма), потом посмотреть, как отработало, поправить, запустить снова и так далее.

Q: а какие языки основные используются?

C++ и Python. SPAdes это проект на С++ с оболочкой на Python. Я в том числе занималась тем, что переписывала эту оболочку там было около десяти тысяч строк кода, и надо было разделить legacy-код, инкапсулировать отдельно составление pipeline и запуски, чтобы запускать на кластере. То есть, на Python тоже довольно много работы, хотя и проект на С++.

У меня так не получается. Если я сосредоточилась и настроилась на дебаг, но после запуска ушла читать статью я к этому дебагу не вернусь. У меня были такие дни, когда было ощущение, что единственное, что я делала в течение дня это ждала выполнения программы. Бывает сложно; ну, такая специфика.

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

Давайте вспомним основы как появляются белки. У нас есть ДНК, и из нее мы получаем РНК; можно представить, что ДНК это большая библиотека, а РНК это небольшая статья, которую мы скопировали и дальше будем работать. Как будто мы пришли в библиотеку и запросили эту статью, но библиотека сами статьи не выдает они слишком ценные, а выдает только копии. И дальше мы с этими копиями работаем; можем выкидывать, можем что угодно делать. После получения РНК получается непосредственно белок; у нас есть рибосома, которая по этой РНК ползет и считывает (синтезирует) белок. Она считывает по три буквы, которые есть в РНК: алфавит примерно такой же, как в ДНК, копирование почти 1 в 1. По этим трем буквам определяется, какая должна быть аминокислота; а аминокислоты это уже алфавит, из которого состоит белок. Появляется цепочка аминокислот, и она сворачивается в белок.

Но это не единственный механизм синтеза; нерибосомные пептиды получаются по-другому, и как раз ими я занимаюсь. Прикол в том, что про другие способы синтеза белков никто не рассказывает. Я уже на спор рассказываю, чем я занимаюсь: иногда бывает, что новый биолог, закончивший биофак МГУ или СПБГУ, даже по направлению биоинформатики или молекулярной биологии, не знаком с нерибосомными пептидами.

Давайте снова представим геном. Но в этом случае в нем закодирован не сам нужный белок, а комплекс белков, который будет его производить. Производимый белок это и есть нерибосомный пептид, и в этом есть некоторые нюансы.
Кстати, часто в биоинформатике возникает такая проблема: вместо общеизвестных названий алгоритмов и биологических терминов придумываются свои. Биологи часто жалуются.
Белковый комплекс, который непосредственно закодирован в геноме, называется нерибосомная синтетаза. Сложность в том, что мы хотим узнать непосредственно из генома, какой белок она будет производить хотя вместо него зашифрован потенциально огромный, непонятный, сложный белковый комплекс. Но это очень важно для создания антибиотиков, иммунодепрессантов, других медицинских веществ. Понимание механизмов создания белков помогает непосредственно производить вещества (именно с точки зрения фармацевтики). Кроме того, появляются возможности для биоинженерии: понимание механизмов может позволить менять участки генома таким образом, чтобы получать вариацию нерибосомного пептида, которая будет более эффективна как антибиотик, например. Открытие новых антибиотиков очень важно и полезно, потому что периодически появляются устойчивые бактерии из-за того, что очень часто антибиотики прописываются не по делу или принимаются просто так, по ощущениям, без соблюдения курса лечения. В таких случаях антибиотики убивают часть бактерий, но, так как курс лечения не продолжается сколько надо, самые приспособляемые бактерии остаются, и следующие их поколения становятся устойчивыми к примененному препарату. Мораль не пейте антибиотики не по делу, а, если пьете допивайте, как сказал врач. Кстати, пенициллин это, по большей части, нерибосомный пептид.

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

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

А еще этот проект кладезь моего разностороннего развития. Тут важна биологическая легенда то есть, знать биологию действительно надо; надо понимать на некотором уровне органическую химию, чтобы понимать, как образуются связи. У меня была история про придумывание алгоритмов, потом история о том, что пора изучать теорвер и матстатистику; потом неожиданно понадобилась веб-разработка, потому что этим инструментом пользуются биологи а они не хотят работать через командную строку, им нужен нормальный интерфейс (и мне тоже). А я программирование всего 10 лет изучаю! Потом я разбиралась, как настроить NGINX, чтобы сервис заработал.

Очень много анализа данных, разбора в том, как эти данные устроены и откуда их брать (находить их очень большая проблема). В какой-то момент это меня демотивировало приходилось развиваться в многих различных областях одновременно; было такое ощущение любить всех не любить никого. Есть же такие люди, которые занимаются чем-то одним и разбираются в этом очень хорошо: если это веб-разработка, то этот человек любой сайт с закрытыми глазами сверстает, например. А у меня пошла такая история, что я вроде как изучаю сразу все. Сейчас я уже стала относиться к этому по-другому, и мне стало легче жить с этим то есть, да, я изучаю много всего и не так глубоко, как хотелось бы; ну, может быть, лет через 40 я буду знать все эти области так глубоко, как мне хочется.

Сейчас еще существует история про Machine Learning (ML). У нас есть ребята из etBrains Research, которые в этом проекте занимаются ML почему-то там постоянно появляются люди, которые хотят заниматься этим проектом. Они пытаются применять Hidden Markov Model, чтобы решать эту задачу. Кстати, когда я рассказывала нашим коллегам из JetBrains про задачу просто про то, как она устроена, какие важные места надо учитывать моя собеседница сказала: наверно, ты в лаборатории биолог? Видимо, я теперь могу производить впечатление настоящего биолога.
Перейду на третий проект центромеры. Я начала заниматься им совсем недавно, в сентябре помню, как обрадовалась, когда мне предложили заниматься им.

Но сначала хочу рассказать байку про еще одну специфику биоинформатики. Я сейчас на шестом курсе учусь, с сентября начались курсы, в том числе программирования на GPU. Я читаю домашнее задание и думаю: в чем здесь смысл? Тут же задача уже сформулирована и сказано, что надо сделать. Есть еще такая история: хочется чего-то сделать, есть примерное понимание того, что нужно получить в итоге но только на уровне сделать все хорошо, а что именно хочется получить непонятно.

Итак, центромеры; здесь должно быть проще, чем с нерибосомными пептидами. Представьте себе хромосому ту самую картинку, похожую на Х. На самом деле, она принимает такую форму только в процессе деления клетки. В этот момент генетическая информация дважды продублирована, и эта буква на самом деле две сестринские хроматиды. То место, где они сцепляются это как раз и есть центромера, которую интересно изучать. Потом эти хроматиды растаскиваются за центромеру на разные части клетки.

Центромера этот тот регион хромосомы, который до недавнего времени (буквально до этого года) не был собран. Он достаточно сложен. Сейчас появились новые способы секвенирования генома более длинные риды (те самые кусочки газет из метафоры), более качественные, возможность гораздо лучше собирать геном. Есть T2T Consortium это сообщество ученых, которые хотят собрать геном от теломеры до теломеры. Теломера это такой участок хромосомы, который показывает возраст клетки; каждый раз, когда клетка делится, от теломеры отрезается часть, и поэтому количество возможных делений клетки ограничено. Сейчас уже создана первая чистая версия генома человека, в которой собраны все участки. Возможно, если вы интересуетесь научно-популярной биоинформатикой, вы слышали, что в 90-х годах был Проект генома человека, и в начале 00-х он как бы завершился; об этом писали большие статьи в журналах якобы, мы теперь все знаем о жизни. На самом деле, та версия совсем не была полной. Там было множество участков типа здесь слишком сложно, пока мы его оставим, когда-нибудь потом дособираем. Сейчас именно это и было сделано; центромера это как раз очень сложный для сборки участок. С точки зрения строки это история про тандемные повторы. То есть, у нас есть коротенькая строчка, которая повторяется очень много раз на этом участке. Причем повторяется не полностью: различные повторения могут отличаться на пару нуклеотидов. Но мы хотим все это восстановить. Обычно используется X-хромосома: её собирать и изучать удобнее всего, потому что она у мальчиков только одна; если хромосом две все усложняется.

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

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

Q: Циклы C++

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

Чем мне этото проект очень нравится так это тем, что это первый проект, в которым я работаю с крупными учеными. Им активно занимается Павел Певзнер очень крутой алгоритмист, и у него есть такой очень крутой скилл: переводить непонятную биологическую задачу в строгую математическую. Он умеет построить и сформулировать модель для этого, что очень сложно и очень важно. Формулировка задачи это значительная часть работы, сформулированная задача уже наполовину решена. Еще я работаю с Иваном Александровым это человек, который очень много занимался центромерами. С ним комфортно общаться, я периодически приношу ему новые данные и мы их совместно разбираем. Он активно интересуется тем, что я делаю, дает рекомендации. На последней встрече был забавный эпизод: я рассказывала ему про мономеры, которые я делаю, а Иван рассказывал мне про классификацию данных повторов в центромере. Я спросила, где можно про это прочитать, и он предложил мне большую обзорную статью по классификации данных в центромере, которую он сам написал в 2001 году. Он писал большие обзорные статьи, когда я еще читать не умела! И, когда я читала эту статью, я нашла ссылки на другие статьи Ивана по центромерам одну из них он написал в 1986 году! То, что у меня есть возможность работать с этими людьми и учиться у них это очень ценно для меня, мне действительно интересно быть здесь и получать здесь опыт.

Q: Как к вам в лабораторию попали люди с несоответствующим образованием?

Я не очень знаю, как попадать к нам. Условно, простой способ выглядит так: если вы студент, например, института биоинформатики или каких-нибудь программистских университетов СПБГУ, питерской вышки и так далее то у нас есть проекты. Можно, как сделала я на втором курсе, приходить, брать проекты, работать с нами. Какие-то люди нам нравятся, приживаются у нас, после этого мы берем их к себе работать. Еще у нас есть летняя стажировка; каждый год она набирается по-разному, в мой год было 10 человек. В лабораторию набирают стажеров, смотрят, кто нравится, кто не нравится, кто как приживается. При этом я начинала свою карьеру в биоинформатике, не зная о биологии почти ничего, и прижилась.
Насчет несоответствия я не очень поняла. Оно как раз соответствует.

Реклама! Приходите к нам работать в СПБГУ. Есть еще питерская вышка; я закончила АУ, это очень классное место, я очень довольна, что туда поступила. Сейчас наша образовательная программа переехала в питерскую вышку, все люди, которые делают нашу программу, переехали туда. Там очень сильное программистское образование, если вы думаете, куда поступать рекомендую ее.
В статье на Хабре я дам ссылку на свой телеграм-канал.

Еще хотела рассказать про английский. Он у меня вообще не прогрессировал с 1 класса, в 10 классе у меня все еще было elementary. Но потом я нашла хорошую преподавательницу, и английский начал очень быстро прогрессировать. Я считаю, что это преподавательница, которая супер круто занимается с технарями, с людьми с техническим складом, и очень сильно прогрессирует английский. И поэтому я хочу ее посоветовать, к ней можно обращаться.

Q: как переключаетесь между проектами?

Ну, один день один проект, другой день другой проект.

Cсылки:

Сайт нашей лабы.
Группа лабы в ВК.
Мой блог в телеграмме.
Образовательная бакалаврская программа в Питерской Вышке.
Моя статья про SE магу в Питерской Вышке.
Хорошая преподавательница английского по скайпу: skype: evgeniya.prischepova

---

Что было ранее

1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
18. Как Data Science продает вам рекламу? Интервью с инженером Unity
19. Как я переехал в Лондон c Revolut
20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
21. Как организовать IT-конференцию и не сойти с ума
22. Чем биоинформатика отличается от вычислительной биологии краткое введение
23. Профессия системный аналитик: развитие сообществ, популяризация профессии и подготовка

Завтра, 23 ноября, в 20:00 в наших соцсетях выступит Андрей Письменный, главный редактор Xakep.ru.

Андрей начал карьеру в ИТ-журналистике в 2006 году, когда параллельно с учебой в техническом вузе начал писать для Компьюленты одного из первых онлайн-СМИ в России. Вскоре занял должность редактора в Компьютерре, где работал над онлайновой версией журнала.

Андрей успел посотрудничать как автор и редактор со многими российскими ИТ-изданиями: Mobi, Nomobile, Ferra.ru, Игромания, Железо и другими. С 2013 года список пополнил журнал Хакер, а в 2015 году Андрей стал его шеф-редактором. Перед командой тогда стояла задача превратить культовый журнал для компьютерных хулиганов в успешное цифровое издание с подписной моделью. Планы удалось реализовать.

Письменный автор сотен статей, посвященных технологиям, науке и бизнесу. В роли редактора он помогал авторов обрести свой слог, оформлять идеи в связные истории.

В этом выступлении он поделится с вами опытом и приемами, которые пригодятся в работе с текстом о технологиях.

О чем расскажет Андрей

• Вступление: вкратце про меня и про Хакер
• Почему технарь должен уметь писать
• Как найти, выбрать и сформулировать интересную тему
• Как победить чистый лист
• Как писать лучше: простые советы для тех, кто не хочет читать учебник
• Как заставить себя дописать статью
• Разбор примеров текста

Кроме того вы можете задать вопрос Андрею здесь в комментариях или в инстаграме и он ответит на них в прямом эфире.

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Недавно на нашем ютуб-канале выступил Андрей Письменный, главный редактор Xakep.ru.

Письменный автор сотен статей, посвященных технологиям, науке и бизнесу. В роли редактора он помогал авторам обрести свой слог, оформлять идеи в связные истории.

В этом выступлении он поделится с вами опытом и приемами, которые пригодятся в работе с текстом о технологиях.

Делимся записью эфира и расшифровкой.

Меня зовут Андрей Письменный, я работаю главным редактором в журнале XAKEP. Думаю, никому не нужно рассказывать, что такое XAKEP. Я работаю в индустрии уже 14 лет, успел поработать, наверно, во всех крупных издательских домах с тематикой IT ТехноМир (он же ИгроМир), Компьютерра.

Присоединился к журналу XAKEP я только в 2015 году, поэтому его историю я хорошо знаю только за последние пять лет. Те легенды, которые людям, наверно, интересно было бы услышать (и о которых меня просили в комментариях на Хабре), для меня тоже легенды. Сегодня я, в основном, буду рассказывать о том, в чем разбираюсь лучше всего: в приемах, которые помогают писать технические статьи и делать их лучше. Про работу в XAKEPе я тоже рад рассказывать, но это, скорее, будет в ответах на вопросы.

Я начинал конкретно в Компьюленте это такой новостной сайт при журнале Компьютерра: писал там первые полгода крошечные новости, по 500 знаков. Для меня это был лучший опыт. Не говорю, что именно так все должны начинать, но опыт прочтения статей и новостей на английском языке и сжатый раз в десять (обычно приблизительно с 5000 знаков) их пересказ это то, что помогает научиться писать лучше с нуля, отсекая все лишнее. Ну, и английский язык я подтянул, конечно сегодня это необходимо всем, кому нужно работать с источниками. Не с Google Translate же работать. В Комьютерре я проработал в сумме примерно 10 лет, на недолгое время уходил в ТехноМир работать над журналом Mobi. В 2013 году у меня был опыт фриланса, чуть меньше года, когда я писал для различных изданий. Среди них оказался и XAKEP! Мы как-то сразу друг друга нашли, и я начал периодически писать туда. В 2015 году я работал в Ferra.ru, и меня пригласили в XAKEP редактором. Два года назад я стал главным редактором.

Про XAKEP я, конечно, знал давно. Году в 2000 впервые увидел выпуск, купил, прочитал, протащился от того, насколько отвязные вещи, оказывается, можно публиковать на бумаге. В те времена это потрясало, кончено. Сейчас аудитория повзрослела, реалии тоже изменились. Вообще, в тот момент, когда я пришел в журнал в 2015 году он переживал большой перелом. Я застал выпуск последних трех бумажных номеров перед тем, как его перевели полностью в онлайн. От редакции решение по закрытию бумажного издания, к сожалению, не зависело, но в онлайне мы себя прекрасно чувствуем. Мне эта модель близка: мне нравится, что мы публикуем статьи для подписчиков и берем деньги с людей непосредственно за возможность читать журнал. Я очень благодарен нашим подписчикам за то, что они делают это возможным. Мы не зависим от рекламы, никто не диктует нам, что делать, кроме наших читателей это круто, я очень рад, что это сработало. Это позволяет нам платить авторам и тщательно подходить к вопросам редактуры статей.

Скажу по секрету: хакеры пишут ужасающе! Работа редактором в журнале XAKEP это для меня классный челлендж, я таких текстов раньше не встречал. Я не говорю это кому-то в обиду. Дело в том, что хакер это такой технарь, который не строит, а с помощью своей интуиции понимает, как работают сложные системы. У него, в отличие от инженера, часто в голове бывает прекрасный хаос, который помогает находить интуитивные решения. Ну, и пишет он соответствующим образом а мы помогаем все это вытягивать на тот уровень, когда человек может зайти и прочитать текст, и это не будет слишком затруднительно.

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

Раз уж мы заговорили о школе: нас, конечно, учат писать, но не так, как следовало бы. Например, американские ученики постоянно пишут эссе (может, вы это наблюдали в литературе или в сериалах), и такие эссе не равняются сочинениям по литературе. Они могут быть по разным предметам, и с помощью них люди учатся писать о разных вещах. У нас такой практики нет, и на литературе просто учат грамотно писать все слова при повторении того, что было на уроке. Здесь, к сожалению, возникает проблема с умением писать. Проблемы возникают и с умением аргументированно спорить у нас этому не учат, хотя стоило бы.

Первый этап написания статьи это поиск темы. Иногда она известна заранее: то есть, ты садишься описывать (или тебя просят описать) что-то, что ты знаешь. Но так бывает не всегда. Новые авторы часто ломают головы по этому поводу. Человек может делать очень крутые вещи, но понять, какая тема в этой большой вещи интересна, всегда нетривиально. Я рекомендую думать, о чем крутом ты бы мог рассказать, когда рассказываешь о своей работе. Может быть, вспомнить, какие истории недавно кому-то рассказывал. То, о чем действительно хотелось бы рассказать, то, чем действительно горишь в данный момент об это, скорее всего, и стоит писать: тогда получится быстро, хорошо, задорно.

Частая ошибка новых авторов брать слишком глобальную тему. Не надо пытаться вместить в статью то, о чем можно было бы написать трехтомник надо подбирать конкретные темы, задавать рамки. На самом деле, первые несколько статей очень тяжело формулировать, но дальше ты начинаешь все видеть через нужную рамку. Достаточно думать: Что я знаю такого, чего другие не знают?

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

Я не рекомендую брать темы, сводящиеся к существованию чего-то. Лучше брать такие темы, которые раскрывают то, как достигается какая-то цель, или то, почему лучше делать одну вещь, а не другую (например, выбирать определенную программу вместо других), и рассказывать так, чтобы получалось повествование или сравнение. По крайней мере, это говорит мой опыт.
Конечно, бывает так, что разработка темы зашла в тупик, и ее не получается развить по неким объективным причинам. Всегда можно посоветоваться с редактором или рассказать кому-то из знакомых может быть, в этот момент родится другой подход к этой теме, который позволит спасти положение и рассказать об этом по-другому. Часто можно просто пойти и посмотреть (подсмотреть) где-нибудь формат. Новым авторам бывает тяжело придумывать формат статьи и последовательность повествования но их не зазорно подсматривать. Можно рассказывать о другой вещи в том же формате, в том же ключе.

Начинать писать статьи я рекомендую с заголовка. Если удается придумать хороший заголовок значит, дальше все пойдет нормально. Не обязательно зацикливаться на том, чтобы он был особенно красивым или остроумным достаточно, чтобы он был понятным. Остроумие может прийти потом, во время написания, или можно об этом не задумываться. Хороший рабочий заголовок очерчивает рамки дальнейшей работы, и это важно: с авторами мы обычно обсуждаем рабочий заголовок, который будет у статьи. Я еще прошу писать краткую рекламку статьи: о чем она будет, что в ней будет. Это лучшее начало статьи, которого можно ждать.

Я рекомендую делать так, чтобы в заголовке был глагол. Если он есть это значит, что статья описывает действие. Если статья называется, например, протокол TCP/IP скорее всего, это довольно скучная статья, которая просто описывает какую-то существующую вещь. В такой статье автор будет смотреть на эту вещь, и ничего не будет происходить. А вот если статья называется как использовать TCP/IP для какой-то цели, то она гораздо лучше очерчивается и обещает быть веселее, потому что в ней мы что-то делаем, а не описываем что-то.
Часто люди сталкиваются с проблемой чистого листа когда ты садишься и думаешь, о чем же писать. Для таких случаев существует очень действенный совет из народного творчества (уберите детей от экранов): начинайте со слов Так, бля, короче! И дальше текст начинает идти сам собой. Потом, конечно, вступление можно убрать. Такая полу-шутка, но, на самом деле, правда: если начинать в неформальном ключе, то дальше будет легче начинать говорить о какой бы то ни было теме.

Я часто использую прием написать что-нибудь начерно, обычно для этого использую треугольные скобки (у меня в редакторе это подсвечивает текст серым цветом). Можно использовать любые технические приемы: писать курсивом, например, или писать в другом окне редактора. Написание временного текста помогает преодолеть блок, когда ты не можешь что-то сказать красиво или думаешь, что не можешь. Ты потом смотришь на текст и понимаешь: вот, можно тут и тут поправить, и будет нормально. Иногда и править не приходится.

Чего не следует делать, так это писать развесистое предисловие. Если статья начинается с типичного технологии все плотнее входят в нашу жизнь, то редактор это выкинет из текста. У меня даже есть пример, из недавнего: В последние годы люди все чаще используют мобильные телефоны как средство коммуникации с другими людьми. Вы ничего нового никому не сообщаете такими пассажами. Если это помогает ехать дальше можно написать, а потом стереть (или редактор сотрет), но сидеть и специально придумывать заход под подобным нетривиальным углом не нужно. Просто начинайте с дела, а не предисловия или вступления. Можно, закончив текст, вернуться и добавить сжатое содержание статьи в качестве первого абзаца по нему читатель сможет понять, зачем ему читать эту статью. В редактуре я делаю так же: читаю статью, а потом возвращаюсь в начало и пишу лид первый абзац. Иногда он оформляется как-то по-особому в журналах. Лучшие лиды сообщают, зачем человеку читать эту статью это позволяет легко ориентироваться. Я уже говорил, что мы в XAKEPе обычно просим написать короткое описание статьи, на один абзац. Чаще всего оно замечательно идет в качестве лида и позволяет рекламировать статью, например, в соцсетях.

Естественно, большая проблема как писать. Здесь лучше всего объяснять кому-то, кто уже пробовал, у кого есть практика, но некоторые советы дать можно. Главная проблема нового человека, который садится и хочет что-то написать это попытки звучать более авторитетно. Каждый неопытный автор пытается имитировать какой-то стиль, который кажется ему авторитетным например, стиль полицейский протокол или научная статья. Из-за этого желания звучать весомо иногда появляются безумные перлы. Например, метод повышения эффективности использования вредоносных узлов для деанонимизации пользователей даркнета это из реального текста. На слух это вообще не воспринимается, мне кажется. В виде текста я, в принципе, понимаю, что автор хочет передать в этом нанизывании восьми существительных одно на другое. В общем, нужно обязательно думать о том, как человек будет читать текст, и не стараться звучать более умно, чем разумно было бы звучать. В данном случае можно было бы просто написать Как избежать деанона, например.

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

Простое правило: нужно написать все, что нужно, а потом выкинуть все, что не нужно. На практике это, конечно, сложнее сделать. Вообще, есть два важных принципа, которые стоит соблюдать: делать короче и делать честнее. То есть, надо выкидывать все ненужные слова, которые не помогают донести смысл, а еще надо стараться именно донести смысл вместо того, чтобы как-то хитрить. Если вдруг оказывается, что ты пытаешься скрыть отсутствие в тексте какого-то факта это, во-первых, сложно (иногда намного сложнее, чем поиск ответа), и, во-вторых, не нужно. Нужно честно общаться с читателем. Вместо того, чтобы писать недавно многие люди в крупных компаниях..., лучше просто найти, когда именно, кто именно и в каких именно компаниях. То есть, нужно бороться с моментами, создающими неточность. От этого текст будет лучше, информативнее и понятнее. Если в голове, когда пишешь, крутится вопрос его нужно ловить, вытаскивать и отвечать на него. Надо быть честным с собой. Если попытаться это сделать, если отсутствие ясности сформулировать в виде вопроса, то тогда станет ясно, можно ли на него ответить. И, если на него можно ответить, то в статье должен быть ответ. А если ответить нельзя надо прямо об этом написать: здесь может возникнуть вопрос, но ответа у меня, к сожалению, нет. Тогда у читателя будет этот вопрос. Во-первых, возможно, он сам будет знать на него ответ. Во-вторых, он не будет пытаться искать ответ в расплывчатом тексте, и не будет сомневаться в себе и думать а не пропустил ли я ответ на этот важный вопрос, без которого дальнейшее понимание невозможно, когда сам автор не знает ответа. Конечно, не получится всегда это делать, но, если стараться, то тексты будут получаться проще и яснее.

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

Еще одна вещь я такие случаи называю словом вещание. В устной речи или по радио часто объявляют, что сейчас будет что-то. Это нормально, но в статье перед читателем уже находится весь текст. Он сам прекрасно видит, что будет дальше и что было до этого не нужно ничего объявлять. Авторы еще очень любят слова как было сказано выше, напомню, поясню после них они либо повторяют то, что уже было сказано, либо подтверждают, что это уже было сказано. Людям совершенно не нужны подобные напоминания. Если действительно нужно упомянуть какой-то факт снова, то можно просто упомянуть его снова, не обговаривая, или упомянуть как-то по-другому в новом контексте. Я часто выкидываю слова напомню и поясню вместо них можно просто напоминать и пояснять. В английских учебниках это правило называется show, dont tell не говори, а показывай. Не нужно объявлять, что ты сейчас что-то сделаешь, нужно просто делать. Все поймут.

По поводу вещания: часто люди путают статью и радиопередачу. В XAKEPе это почему-то прижилось, и я очень часто вижу тексты, которые начинаются со слова Привет! и заканчиваются До свидания, Stay tuned и так далее. Может быть, это какая-то авторская фишка, и кому-то это прикольно, но для меня это странно. Вроде как человек пытается изображать ди-джея текстом. Обычно мы убираем такие вещи.

Часто встречаются слишком сложные тексты. Может быть, это у людей травма Львом Толстым со школы, и они пытаются бесконечно удлинять предложения. Нужно стремиться работать по простой схеме: подлежащее-сказуемое-дополнение, больше ничего не нужно. Если получается длинно, то лучше разбить на несколько предложений. От скобок почти всегда можно избавиться. Если идут скобки, то можно разделить на два предложения без проблем.

Очень много бывает страдательного залога это когда подлежащее не выполняет действие, а подвергается ему. От этого тоже нужно избавляться. Лучше всего везде иметь действительный залог кто-то совершает что-то. Точно так же можно убирать деепричастия, делить длинные предложения, избавляться от обратного порядка слов. Все эти вещи ухудшают восприятие текста, и их лучше убирать. Редакторы от них избавляются в первую очередь.

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

Бывают еще разные проблемы например, тавтология, но это понятно: этому в школе учат.
Распространенная ошибка в неотредактированных текстах компания совершает действие. Это уже более тонкая вещь, и, в принципе, по первому разу можно не обращать на это внимания и писать, как получится. Редактор сделает. Суть в том, что компания это люди. Только люди совершают действия, а не компании. Еще иногда компанию называют во множественном числе. Microsoft решили, Facebook сделало. Вместо этого можно уточнить, написать инженеры Microsoft или руководство Facebook так будет звучать намного грамотнее.

Заканчивая разговор про стиль: общая рекомендация ловить себя на мысли так сойдет. Голова ненадежная вещь. Здесь так же, как при редактировании кода: ошибка линтера вылетает, но в голове не задерживается, потому что ты думаешь ладно, так все равно будет работать, все поймут, что я имею в виду. Самые страшные ошибки в отношении русского языка и стилистики совершаются именно в такие моменты. Если себя ловить, обдумывать еще раз те решения, на которые ты себе даешь разрешение, то ты будешь ловить и рассогласования, и неправильно построенные предложения все стилистические ошибки.

Советы по стилю, конечно, можно продолжать, сколько угодно по ним есть целые книги. Я думаю, что начинающим авторам нужно знать хотя бы вот это. Конечно, начать писать или написать немного это еще не всё, главное завершить статью. Вся работа пойдет насмарку, если статья не будет дописана. Очень часто авторы исчезают, придумывают удивительные отмазки, рассказывают, что у них все сгорело и так далее. На деле это обычно означает, что человек либо не смог сконцентрироваться и собраться над своей задачей, либо не смог достаточно ясно представить саму задачу. Очень важно понять, хорошо ли ты понимаешь то, о чем собираешься написать. Как только начинаешь задавать себе наводящие вопросы, могут вскрыться всякие проблемы: я не знаю, я бы хотел сначала ознакомиться с этим, я бы хотел спросить или обсудить. Это очень важно. Часто не можешь двигаться, потому что не знаешь, чего конкретно ты не знаешь. Это, пожалуй, самая большая проблема. Заставить себя работать гораздо меньшая проблема, я сам очень люблю отвлекаться на все подряд.

Мессенджеры, твиттер, подписки ютюба, кто-то пишет письма постоянно особенно, если работаешь удаленно. Я очень рекомендую таймеры помодоро (метод помидора) это обычный кухонный таймер. Можно использовать одну из миллиона программ-таймеров из интернета. Многие, кто говорит о продуктивности, рекомендуют простой алгоритм: 15-25 минут напряженной работы, 5-10 минут отдыха. Он настраивается по личным предпочтениям и в зависимости от поставленных задач. Например, писать довольно тяжело, и себе я обычно ставлю всего 15 минут, а потом 5 отдыха. Главное пока эти 15 минут не пройдут, ни на что не отвлекаться. Редко бывают такие сообщения в телеграме, которые не подождут 15 минут.

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

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

Вообще, очень важно всегда искать причину ступора. Если ты вдруг на чем-то остановился и не знаешь, как дальше можно поперечитывать, поразмышлять, понять, чего не хватает.
У меня с продуктивностью всегда было тяжело. Я постоянно отвлекаюсь, хочу делать что-то не то, что нужно, увлекаюсь совершенно побочными задачами. Естественно, приходится особенно, когда делаешь что-то горящее, вроде руководства редакцией изобретать кучу всяких лайфхаков, которые помогают делать так, чтобы задачи не терялись, и вообще не пропасть. Я думаю, многие, кто интересовался продуктивностью, читали книгу Getting Things Done но, к сожалению, она не учитывает электронный рабочий процесс и электронные способы коммуникации. Знать, как это работает, полезно, но применять можно с ограничениями и поправками на жизнь.

Еще одна вещь, которую я люблю это чистый инбокс. Это очень полезно. Знаю, что у людей бывает в почте заброшенная помойка с 700 непрочитанных сообщений, но инбокс это не только электронная почта. Это дела, которые могут копиться в разных местах. Я стараюсь все разгребать, делать так, чтобы ни почтовый клиент, ни другие места не забивались. Надо просто решать быстро, будешь или не будешь ты что-то делать. Если надо кому-то срочно ответить, то можно сделать это в стиле большого начальства, двумя словами часто лучше получить от вас два слова, чем не получить ничего. Это важно для того, чтобы писать: всегда лучше иметь чистую голову, без списка нависающих задач. По Getting Things Done все эти дела нужно выписывать и возвращаться к ним, когда будет время, возможность или контекст, чтобы их сделать.

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

Что еще можно сделать, чтобы улучшить свои навыки письма? Надо читать. Причем читать не только социальные СМИ типа Хабра, где тексты разного качества, но и профессиональные какой-нибудь Коммерсант, Ведомости, Esquire. Хотя Esquire это скорее литературные материалы, на него равняться в технических текстах необязательно. Конечно, чтение само по себе не поможет научиться писать для этого нужно все-таки писать. Хоть как-то. Нужно не стесняться: в следующий раз получится лучше. Без практики здесь никак. Как редактор, я, конечно, рекомендую поработать с редактором, если есть такая возможность. Я сам очень благодарен и главным, и литературным редакторам: пусть они ругались, смеялись, обижали иногда, в некоторых случаях молча правили. Всегда нужно смотреть, почему что-то было исправлено. Если ты понимаешь, почему это было исправлено, то велика вероятность, что ты в следующий раз не допустишь ошибку.

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

Из того, что можно почитать, все рекомендуют Пиши, сокращай Ильяхова. Хорошая книжка. Я не читал целиком, но смотрел, и со всем, что увидел, был согласен. Рад, что кто-то тоже об этом пишет. Есть еще книжка Интернет-журналистика Амзина это бывший редактор раздела Технологии Ленты.ру. Многим нравится книга Слово живое и мертвое Норы Галь, хотя я к ней отношусь с осторожностью там язык не вполне актуальный. Почитать про подходы можно, конечно.

---

Что было ранее

1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
18. Как Data Science продает вам рекламу? Интервью с инженером Unity
19. Как я переехал в Лондон c Revolut
20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
21. Как организовать IT-конференцию и не сойти с ума
22. Чем биоинформатика отличается от вычислительной биологии краткое введение
23. Профессия системный аналитик: развитие сообществ, популяризация профессии и подготовка
24. Три задачи из геномики, которые решают биоинформатики в СПбГУ

Завтра, в 20:00 в наших соцсетях выступит Влад Зайцев энтузиаст биохакерских имплантов.

Сейчас у Влада самого вживлено три чипа прямо в руку: карточка Рокетбанка, с которой он может оплачивать покупки и два пропуска в офис (в здании две системы управления доступом), чтобы экономить время на доставании кошелька.

Влад и его команда уже 5 лет вживляют в людей чипы в качестве хобби. Началось это когда он еще студентом наткнулся на наборы вживления чипов, которые продавал парень из США по имени Амаль Граафстр. Самый дешевый стоил $50 и Влад решил попробовать сделать все самому.



Первым вживленным чипом стала карта Тройка, и это вызвало резонанс в СМИ: историю быстро подхватили городские газеты из-за понятного и броского заголовка.

Откуда взялась эта история с чипами

Первоначально Амаль торговал чипами для животных. Есть такая штука, Europetnet, международная ветеринарная база. Используется, в частности, для связи с хозяевами потерявшихся животных. Собакам и кошкам в холку ставятся чипы, в базу вносятся его серийные номера, клички, возраст, болезни, контакты хозяев и так далее.

Потом Амаль постепенно перешел на чипы, совместимые с системами контроля доступа.

Насколько это распространено и ядро тусовки

Всего ребята вживили несколько сотен чипов.

Тусовка техноэнтузиастов называется Russian Implanted Electronics (чат в Телеграме ProImplantedElectronics), которая состоит в основном из ребят из Москвы и Новосибирска. Там же можно заказать себе чип у Влада.

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

Кратко о технологии что такое RFID?

RFID (Radio Frequency IDentification) это собирательное название всех-всех технологий связи так называемого ближнего поля.

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

А в RFID, несмотря на название, никакого радио, по сути, нет. Это связь ближнего действия, когда какая-то метка что-то передает и что-то получает на очень небольшом расстоянии от сантиметра до нескольких метров. При этом она пассивна, элемента питания там нет.

Передача данных происходит с помощью переменного магнитного поля, как в трансформаторе. Она скорее индукционная, чем радио. Это позволяет делать прикольные вещи, например, запитывать RFID-метку тем же полем, через которое передаётся сигнал.

Чип в метке потребляет очень мало. С помощью антенны он получает от считывателя достаточно энергии, чтобы включиться и что-то сделать.

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

Насколько это легально, как именно вживляется чип, что конкретно можно вживить?

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

Кроме технической части Влад расскажет и об интересных кейсах: например про вживление магнитных имплантов в подушечки пальцев, а именно в дистальную фалангу, где очень много нервных окончаний.



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



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

Краткий план выступления:

• С чего все началось
• Технологии: что такое RFID
• Какие чипы у ребят есть сейчас
• Стеклянные чипы: из чего сделаны, где используются, чем хороши
• Магнитные импланты
• Кастомные импланты
• Что в будущем имплантирования?
• Смешные истории из практики
• Как я вживлял карточку рокетбанка
• Религия и как меня попытались побить на радио за метку зверя

Кроме того вы можете задать вопрос Владу здесь в комментариях.

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Завтра в наших соцсетях выступит Стив Гибсон SEO компании Gearbox Software, которая разрабатывала игры Half-Life: Blue Shift, а также дополнений Half-Life: Opposing Force, Half-Life High Definition Pack и Half-Life: Decay и игру Borderlands.

Интервью будет брать Сергей Уланкин главный редактор Канобу и наш давний друг.

Что интересного делает Gearbox Software: Рассказываем про три ярких проекта компании

Borderlands

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

Игроки вольны пройти весь путь до Убежища как в одиночку, так и в кооперативе на четверых игроков, что придется по вкусу всем поклонникам кооперативных развлечений. В Borderlands есть упрощенная кастомизация персонажа, которая ограничивается лишь цветом брони игрока, а так же вариантами оружия; легионы врагов, большие и очень разнообразные пушки, а так же специальные умения, доступные только какому-то одному классу персонажа, которых всего четыре.

По состоянию на май 2019 года, серия продалась общим тиражом в более чем 43 миллиона копий. Наиболее успешной по продажам стала Borderlands 2, у которой было распространено 20 миллионов копий. В 2016 году на основе сюжета франшизы даже планировали снять кино.

Homeworld: Remastered Collection

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

Этими словами в далеком 1999 году начиналась оригинальная Homeworld, первая в мире по-настоящему трехмерная стратегия в реальном времени, с одной стороны, и захватывающая драматическая сага с другой. Для игровой индустрии она стала тем же, что и Battlestar Galactica для телефантастики, культовым в узких кругах проектом, который можно было либо полюбить с первого взгляда, либо, не проникнувшись, забросить его и никогда больше не вспоминать. Даже с появлением всевозможных идейных подражателей вроде той же Haegemonia, Homeworld всегда оставался где-то в сторонке, любимый преданными поклонниками, так толком и не оспоренный соперниками и подзабытый простыми обывателями.

Вновь разжечь затухшую искру взялись в Gearbox Software, которому права на бренд достались после банкротства прежнего владельца, THQ. И выпустили образцово-показательный пример без пяти минут идеального переиздания культовой классики.

Homeworld Remastered Collection объединили под одной иконкой обе номерные части космической саги, причем каждую в двух версиях: обновленной и классической.

Игра получила высокое признание критиков и рейтинг 95 из 100 на igdb.com

Duke Nukem 3D: 20th Anniversary World Tour

Duke Nukem 3D стал шансом вернуться в 1996 год и снова задать трепку пришельцам. Великий герой в очередной раз спасает мир а по дороге разбирается с ужасными монстрами и спасает прекрасных девушек.

Актёр Джон Сент-Джон (John St. John), подаривший Дюку его неподражаемый голос, перезаписал все старые фразы и расширил список новыми. Было улучшено и качество звука.

Разработчики Duke Nukem 3D: 20th Anniversary World Tour не задавались целью перезапустить франшизу или заставить людей переосмыслить своё отношение к игре. Получился хороший подарок для поклонников Дюка Нукема с новой главой, выдержанной в лучших традициях оригинала, а заодно неплохое предложение для желающих в полной мере прочувствовать все особенности шутера 90-х.

Как задать Стиву вопрос?

Вы можете написать его в комментариях и Стив ответит на ваш вопрос в прямом эфире.

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Завтра в наших соцсетях выступит Стив Гибсон CEO компании Gearbox Software, которая разрабатывала игры Half-Life: Blue Shift, а также дополнений Half-Life: Opposing Force, Half-Life High Definition Pack и Half-Life: Decay и игру Borderlands.

Интервью будет брать Сергей Уланкин главный редактор Канобу и наш давний друг.

Что интересного делает Gearbox Software: Рассказываем про три ярких проекта компании

Borderlands

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

Игроки вольны пройти весь путь до Убежища как в одиночку, так и в кооперативе на четверых игроков, что придется по вкусу всем поклонникам кооперативных развлечений. В Borderlands есть упрощенная кастомизация персонажа, которая ограничивается лишь цветом брони игрока, а так же вариантами оружия; легионы врагов, большие и очень разнообразные пушки, а так же специальные умения, доступные только какому-то одному классу персонажа, которых всего четыре.

По состоянию на май 2019 года, серия продалась общим тиражом в более чем 43 миллиона копий. Наиболее успешной по продажам стала Borderlands 2, у которой было распространено 20 миллионов копий. В 2016 году на основе сюжета франшизы даже планировали снять кино.

Homeworld: Remastered Collection

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

Этими словами в далеком 1999 году начиналась оригинальная Homeworld, первая в мире по-настоящему трехмерная стратегия в реальном времени, с одной стороны, и захватывающая драматическая сага с другой. Для игровой индустрии она стала тем же, что и Battlestar Galactica для телефантастики, культовым в узких кругах проектом, который можно было либо полюбить с первого взгляда, либо, не проникнувшись, забросить его и никогда больше не вспоминать. Даже с появлением всевозможных идейных подражателей вроде той же Haegemonia, Homeworld всегда оставался где-то в сторонке, любимый преданными поклонниками, так толком и не оспоренный соперниками и подзабытый простыми обывателями.

Вновь разжечь затухшую искру взялись в Gearbox Software, которому права на бренд достались после банкротства прежнего владельца, THQ. И выпустили образцово-показательный пример без пяти минут идеального переиздания культовой классики.

Homeworld Remastered Collection объединили под одной иконкой обе номерные части космической саги, причем каждую в двух версиях: обновленной и классической.

Игра получила высокое признание критиков и рейтинг 95 из 100 на igdb.com

Duke Nukem 3D: 20th Anniversary World Tour

Duke Nukem 3D стал шансом вернуться в 1996 год и снова задать трепку пришельцам. Великий герой в очередной раз спасает мир а по дороге разбирается с ужасными монстрами и спасает прекрасных девушек.

Актёр Джон Сент-Джон (John St. John), подаривший Дюку его неподражаемый голос, перезаписал все старые фразы и расширил список новыми. Было улучшено и качество звука.

Разработчики Duke Nukem 3D: 20th Anniversary World Tour не задавались целью перезапустить франшизу или заставить людей переосмыслить своё отношение к игре. Получился хороший подарок для поклонников Дюка Нукема с новой главой, выдержанной в лучших традициях оригинала, а заодно неплохое предложение для желающих в полной мере прочувствовать все особенности шутера 90-х.

Как задать Стиву вопрос?

Вы можете написать его в комментариях и Стив ответит на ваш вопрос в прямом эфире.

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Завтра, в 20:00 в наших соцсетях выступит Данил Емелин, инженер-протезист в компании Моторика. Они занимаются созданием протезов верхних конечностей, 80% их пациентов дети.

Ребята делают два вида протезов:

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

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

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

Протезы полностью оплачивает государство

Протезы довольно дорогие обычный протез кисти (механика без компьютеризации) стоит 150-200 тысяч рублей. Компьютеризированный протез 2-2,5 миллиона рублей. Но самое замечательное то, что пациенты получают его бесплатно по ОМС ребята из Моторика добились того, чтобы протезы выдавались за счет государственной компенсации.

Киборги в команде

Сейчас команде Моторкиа около 50 человек: в основном это менеджеры, продажники, конструкторский отдел (RND), электронщики, программисты и самый большой костяк отдел производства протезов (сборка и наладка). Данил в компании уже 5 лет, с самого основания раньше был соучередителем компании, но продал свою долю и теперь работает себе в удовольствие.

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

О чем расскажет Данил на эфире

• как российское отделение Marvel нарисовали и выпустили комикс про их маленького пациента
• как Данил пришел в протезирование
• почему протезы для детей должны выглядеть футуристично, а не имитировать настоящие конечности
• протезы из Lego почему они никак не можем договориться
• откуда берутся маленькие пациенты, нуждающиеся в протезах и почему они совершенно не нуждаются в жалости
• как люди адаптируются к протезам
• как устроен бионический протез
• олимпийские игры для киборгов как Моторика зародила российскую версию соревнований

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

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Завтра, 28 декабря в 20:00 у нас выступает Артем Попов тимлид команды VK Performance Advertising.

Артем руководит командой, которая занимается задачами, связанными с Data Science в рекламе. Их задача делать рекламу в ВК эффективнее и выгодней.

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

Артем расскажет про интересные задачи для дата-саентистов в мире рекламы.

О чем пойдет речь на эфире

• рекламные технологии: какие интересные вещи есть в рекламе
• рекламные аукционы, как они устроены и какие там есть интересные задачи
• что интересного происходит в дизайне аукционов
• в чем сложность предсказания отклика пользователя, например, клика на рекламу, подписки на сообщество или покупки в интернет-магазине
• стратегии проведения рекламных компаний
• ML in production: с каким трудностями и каким сложностями сталкиваются новички в продуктовых командах, которые долго занимаются одним и тем же продуктом
• как меняется жизнь разработчика после попадания в такую команду и как надо работать, чтобы все было хорошо
• как быть классным разработчиком ML-продуктов с точки зрения софт-скиллов
• какие сложности на разработчка накладывает то, что ML сфера предположений и ты не знаешь, как именно придешь к результату
• чего не хватает ребятам, которые на старте карьеры приходят заниматься задачами связанными с Data Science

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Недавно в наших соцсетиях выступал Стив Гибсон президент компании GearBox Software, которая которая разрабатывала игры Half-Life: Blue Shift, а также дополнений Half-Life: Opposing Force, Half-Life High Definition Pack и Half-Life: Decay и игру Borderlands.

Делимся с вами расшифровкой и записью интервью.

Спикеры:

Стив Гибсон
Президент издательства Gearbox Publishing

Сергей Уланкин
Главред Канобу

---

Здравствуйте. Здравствуйте, все, здравствуйте, наши слушатели, и поприветствуем Стива Гибсона, президента Gearbox Publishing. Как дела?

Отлично. А у вас?


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

Но для начала, не могли бы вы объяснить нашим слушателям, чем именно вы занимаетесь в Gearbox Publishing.

В широком смысле, мы берем игры, которые зачастую и финансируем, и делаем так, чтобы как можно больше людей увидели их везде. Возьмите любую игру, которая вам нравится, и задумайтесь, как она работает на Nintendo Switch. Это тоже будет работа издателя. Мы люди, которые делают так, чтобы игра хорошо работала на этой платформе и чтобы как можно больше людей узнали об игре. Также мы делаем рекламу по всему свету. В общем, роль издателя игр доставить игру в разные места.

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

Да. Это началось, когда мы в Gearbox приобрели права на франшизу Homeworld. Многие в команде любили ее, и мы хотели показать ее огромному количеству людей. Мы хотели сделать ремастер, чтобы она выглядела еще лучше. Так что мы подумали: Окей, у нас есть крутая игра, и мы знаем, что людям она понравится. Как мы дадим людям знать о ней?. Так что мы начали разговаривать с издателями, так как сами тогда не издавали игры. И они говорили, что согласятся издавать эту игру только в том случае, если мы подпишемся еще и на издательство следующих частей Borderlands у них же. За нас была вот такая конкуренция.

Так что нам стало понятно, что если мы хотим дать людям сыграть в такую крутую игру, как Homeworld, и при этом не закладывать в контракт свое собственное будущее и другие наши игры, то нам нужно сделать все самим. Так что начали этим заниматься, все продумали, и через год-полтора Homeworld Remastered увидела свет. И это был большой успех. Если еще и игра отличная, то это, конечно, помогает, верно? (смеется). Но мы очень многому научились и поняли, что у нас в компании есть правильные люди. И с этой работы с Homeworld мы стали строить свое издательство.

Вы думаете, что это естественный процесс, когда игровая компания растет, растет ее база фанатов, и потом она использует базу фанатов, чтобы превратиться в издателя? Или же это большой риск, на который пойдёт не каждая растущая компания?

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

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

И это взаимовыгодно. Мы строим большого издателя для Gearbox Games, но в то же время появляется возможность применить наши знания к чужим играм. Это правильно для бизнеса, чтобы мы издавали больше игры, и это правильно для Gearbox в целом, чтобы компания получала пользу от постоянного приобретения новых знаний. У нас получился гибрид: мы и свои игры издаем, и чужие в основном чужие, и так скорее всего и будет оставаться. По крайней мере до тех пор, пока Gearbox Software не вырастет так, что начнет выпускать по игре каждый квартал.

Мне кажется, что в индустрии, по крайней мере с точки зрения игрока, всегда противопоставляли издателей и разработчиков. Разработчики это творческие ребята, которые создают игры ради искусства и признания. А издатели это ребята, которые делают деньги, а следовательно злодеи. Можете попытаться развеять этот миф?

О, господи! Для создателя игр это такая шкала, где с одного конца находится художник, который созидает для себя, а с другой стороны коммерческий художник, который всегда задумывается над тем, чтобы сделать нечто, что понравится другим людям, и они купят это за деньги. Так что все начинается с самого разработчика. Нужно сперва понять, кто такой разработчик игр и для кого он создает? Он это делает, чтобы себя порадовать, или же думает о потенциальных клиентах? И в тот момент, когда он принимают это решение, он уже думает о деньгах как разработчик.

Допустим, я не играю в кооперативные игры, но знаю, что многим людям они нравятся. Так думает создатель игр и делает свою игру кооперативной. Зачем ты так сделал? Это же было решение не для тебя, а для коммерческого успеха. Так что все начинается с разработчика, который уже принимает решение о коммерческой составляющей.

Давайте поднимемся на следующую ступеньку, когда издатель получает игру. Издатель уже ничего с ней не делает, ведь он только вторая часть уравнения. Он думает: Ну ладно, вы сделали кооперативную игру. А теперь я как издатель буду решать, как потратить время и деньги, чтобы продавать это так, чтобы люди купили. Чтобы люди увидели игру и захотели её.

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

Но можно развеять хотя бы ту часть про то, что вы злые.


Ах да, об этом! Когда видишь, что издатель поставил рекорд по прибыли и тут же сокращает 15% штата. Вот такие вещи иногда происходят.

Кажется, я понимаю, про кого вы говорите.


Просто случайный пример.


Это случайно похоже на новости об Activision Blizzard около года назад.


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

Так что в краткосрочной перспективе, когда компании принимают решение о следующем квартале или паре кварталов, они думают: Ну ладно, этим людям нечем заняться. Это правильное финансовое решение, когда ты думаешь об итоговой прибыли компании или инвесторов.

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

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

А почему с тех пор, как у вас появилось собственное издательство, вы не издаете все собственные игры сами? Почему, например, вы не издаете Borderlands 3?

Ой, ну это просто. 2K прекрасный издатель, честное слово. Как я уже говорил, они берут на себя финансовый риск создания Borderlands. И в 2K работает огромное количество людей, которые без сомнения хотят, чтобы об игре узнали как можно больше игроков.

2K не просит от нас ничего, кроме того, чтобы мы продолжали делать Borderlands, чтобы они их издавали. Мне кажется, что они делают хорошую работу. Так что все очень просто. Если бы нам не нравилось, как они работают, то мы бы думали по-другому. Но мы работаем уже 10 лет, и у нас почти не было проблем. Изменилось только то, что у нас у самих появился издатель, так что мы теперь больше понимаем, почему 2K просил нас сделать какую-нибудь, с нашей точки зрения, глупость. И теперь как издатель мы понимаем: Ах, так вот почему. Сейчас мы лучше всего понимаем, что 2K это отличный издатель, теперь мы только больше убеждаемся в этом. Я думаю, что мы с ними продолжим работать, даже несмотря на то, что мы издаем собственные игры. Даже в этом случае мы с ними будем разговаривать, потому что верим в их способности. Мне они очень нравятся, они хорошие люди.

Давайте я просто уточню, что здесь есть еще и проблема масштаба. Вы говорили, что у вас маленький издатель, а Borderlands это большая игра, правильно? Так что ей нужен большой издатель.

Да, точно. 2K огромные. Это тоже важный фактор. Они очень хороши на этом уровне, а мы намного меньше. Так что есть много причин, чтобы и дальше работать вместе.

А с какими играми вы как издатель предпочитаете работать? У вас есть предпочтения с точки зрения жанра или может быть самого бизнеса разработчика?

Мы начали с того, что мы знаем. То есть с игр про лут, с ролевых экшнов и с кооперативных игр. Это все можно увидеть в играх, с которыми мы работали. И еще шутеры! Одной из первых изданных нами игр была Bulletstorm чистый шутер, который был во многом похож на Duke Nukem, с которым мы тоже работали как издатель и правообладатель. Возьмем Risk of Rain кооперативная шутер с лутом, но только от третьего лица. А теперь Godfall тоже кооперативная игра с лутом, но с ближним боем, а не стрельбой.

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

Предположим, что я сделал милую игру про младенцев с бензопилами. И с точки зрения игрового процесса это паззл. Что мне нужно сделать, чтобы вы издали мою игру?

(смеется) Ну это сразу берем! Без проблем. Если это абсолютно новая игра с абсолютно новой идеей, то в первую очередь мы собираем группу по оценке игры, которая состоит из нескольких типов людей: кто-то оценивает продакшн, кто-то визуальную часть, кто-то дизайн. А ещё это должны быть люди с разным жизненным опытом мужчины, женщины, а еще разных национальностей. Мы как издатель должны убедиться, что мы будем издавать игру, которая будет интересна не только одному единственному белому мужчине 35 лет. Мы проводим большую работу, чтобы понять, есть ли здесь потенциал для бизнеса. Как вы решили сделать такую игру? Чем вы хотите, чтобы она оказалась?

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

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

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

Допустим, у вас есть отличная игра про младенцев с бензопилами. Но мы говорим: Слушай, дружище, оказывается в Австралии есть законы об изображении наркотиков, а в твоей игре нужно принимать наркотики, чтобы лучше управляться с бензопилой. У вас есть выбор: не запускать игру в Австралии или же поменять что-то в игре, чтобы ее можно было там продавать. Важно, как разработчик отреагирует на это. И конечно мы как издатель пойдем спорить с правительством Австралии, чтобы доказать им, что они все поняли в игре неправильно.

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

По правде говоря, в игре Risk of Rain присутствовала игла, которую нужно использовать, когда вы делаете укол адреналина. И в некоторых странах мы заметили сильную реакцию на изображение иглы. Что прикажете с этим делать? Вот о чем мы думаем: как хорошо разработчик будет работать со всем миром, а не только с той страной, где живет он сам.

Можете вспомнить какую-нибудь странную вещь, которую пришлось вырезать из игры?

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

В Risk of Rain была ситуация, когда враг выглядел как череп. Мы решили, что в Китае нужно это исправить. Я не знаю, как он будет выглядеть в итоге, это уже решают разработчики. Но мы им говорим, что вот два варианта: либо нет официального релиза в Китае, либо вы находите творческий способ сделать так, чтобы этот враг не выглядел как скелет и при этом оставался страшным. Нам повезло, что у нас не было больших проблем, подобных этой.

Еще могу рассказать про другую игру и Китай. Мы издавали We Happy Few, где вся суть сюжета в том, что правительство вас обманывает, и мир на самом деле не такой, как кажется. И мы даже не пытались. Мы понимали, что это вызовет проблемы, так что поговорили с Compulsion, разработчиками игры, чтобы убедиться, что мы не сможем поменять всю игру. В итоге мы даже официально не подавали заявку, потому что понимали, что тематика игры не подходит под их культуру. Так что да, бывает и так.

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

---

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

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

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

Я бы хотел задать последний вопрос об издательстве и маркетинге игр. Вы работаете над маркетингом в Gearbox уже больше 10 лет, так? Можете кратко назвать три вещи, которые изменились за эти десять лет в маркетинге игр?

Ну многие люди снаружи путают маркетинг и пиар. Это очень разные вещи. Можно как бы разделить это на то, что заслужили, и то, за что заплатили. Пиар это когда вы не платите никому, но попадаете на обложку журнала Game Informer. Так происходит из-за взаимоотношений с редактором, который знает или думает, что вы делаете отличную игру, и хочет рассказать об этом всему свету. Вот это пиар.

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

Изменилось и то, где теперь покупатели не у стендов с прессой, а на стриминговых платформах и сайтах. Это тоже изменение.

А еще, как мне кажется, произошла вот такая вещь, которая полезна покупателям и которая сейчас почти не случается мы называем это авдерториал (от слов реклама и редакция). Вы могли видеть вебсайты, которые смешивают две вещи. Эй, я слышал, что этот издатель купит рекламу на два миллиона долларов, но только если мы напишем вот это превью игры, где мы уделим ей много внимания и расскажем, какая классная она выйдет. Вот это происходило раньше чаще, чем мне хотелось бы как человеку, который работал на сайте. Я видел такие запросы.

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

Вот еще одно улучшение. Розничные продажи теперь не так важны с точки зрения маркетинга. Люди любят называть себя прогрессивными и говорить про будущее индустрии, но физические копии все еще составляют огромный процент продаж. В тот момент, когда вы выпустите игру, ваши продажи будут примерно пятьдесят на пятьдесят. В квартальном отчете компания заявит, что 70% их продаж были цифровыми, но это если считать игры на ПК, которые почти на 100% цифровые. А вот на консолях Xbox, PlayStation, Switch пропорция уже будет пятьдесят на пятьдесят.

Даже игры, которые начнут продаваться в эти праздники. Это создает давление на стороне маркетинга, потому что все пытаются создать предзаказы. И когда вы получаете предзаказы, вы должны произвести диски. А когда вы производите диски, это создает риски. А когда есть риск, то бывает так, что люди начинают приукрашивать игру. Этот риск подстрекает людей: Господи, у меня же на складе 10 миллионов дисков. Мне правда нужно, чтобы люди их купили до того, как поймут, что из себя представляет игра.

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

Еще отличным событием для покупателей стало появление Epic Games Store. Люди жалуются на то, как они ведут дела. Уверен, что многим не нравится идея эксклюзивов. Но я уверен, что многие люди и не заметили, как после появления Epic Games Store Valve снизила комиссию с 30% до 25%, а потом до 20%. Уверен, что этого бы не произошло, если бы не пришел Epic и не сделал то, что сделал.

То есть у разработчиков больше денег, а для покупателей это стоит примерно столько же. Выходит, что разработчики получают больше и у них больше мотивации делать новые игры. Вот это сделал Epic Games Store. Они помогли сломать монополию, они стали соперником на монополизированном рынке. Вот это круто для геймеров.

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

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


Представим, что у них это все есть. Кто-нибудь бы к ним пришел?


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

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

Но важно то, что они способствовали тому, что Valve начала шевелиться. И для меня это важно. Покупателям это будет приносить пользу еще многие годы. Когда есть разные магазины это, я думаю, отлично для всех нас и для издателей, и для игроков. Поэтому вы и хотите, чтобы были успешны и Sony, и Microsoft, и Nintendo. Вы хотите, чтобы на рынке была конкуренция, ведь именно это заставляет людей стремиться к лучшему.

Epic Games делает то же самое, по крайней мере начали делать, и на мобильных устройствах.

Да. Вы видели, что Apple странно и внезапно анонсировала программу, где вы должны платить уже всего 15%.

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

Я согласен. Со стороны Apple это было очень умно. Но это и прекрасно. Мне наплевать, какие были причины, но что случилось, то случилось. А причина этому конкуренция на рынке.

Хорошо. Я бы также хотел поговорить про былые времена, раз вы вспоминали, как руководили новостным сайтом и работали журналистом, а позже просто были владельцем. Давайте поговорим про ShackNews: как вы его создали, каким он был и каким стал в конце.

Ну, я всегда был владельцем, потому что я был основателем.


Да, я имею в виду, что вы, возможно, я надеюсь, перестали делать грязную работу и писать тексты самостоятельно.

Ну да, со временем я стал тратить больше времени на другие задачи.

Я запустил ShackNews, когда перевелся из колледжа в Техасе в колледж во Флориде. В Техасе я познакомился с видеоиграми и играл до посинения. Я начал играть в Doom 2, и блин, это было круто. Потом я переехал в колледж во Флориде, и где-то шесть месяцев спустя я начал очень много играть в игры. Когда я переехал, я никого не знал, но я знал, что люблю игры, так что я решил сделать сайт, где мог бы рассказывать про еще не вышедшую новую игру на тот момент это был Quake. Так и сделал, запустил сайт, где я писал про предстоящий запуск Quake. А еще делился новостями и информацией про другие связанные игры, то есть много про Doom.

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

А я понял, что я не отношусь к таким людям. Я люблю делать так, чтобы люди знали о существовании такого вида развлечения. Вот это просто странно. Этим я занимался показывал людям то, что им стоит увидеть, потому что мне это казалось крутым.

Спустя 12 лет я устал работать из дома. Сейчас смешно про это говорить. В общем, я устал, сказал своей жене, что я больше так не могу: я вкалываю часами, сижу в стуле как приклеенный, а сам даже мира не видал. Так что я решил продать ShackNews. Не знаю, где я буду работать, но не здесь, вот так. И продал.

Я живу в том же городе, что и несколько друзей, которые работают в Gearbox. Я заявил им: Привет, ребята! Я продаю сайт и не знаю, что буду делать дальше. И там был Рэнди Питчфорд, и он сказал: Не знаю, что ты будешь делать дальше, но наверняка это будет интересно. И держу пари, я был бы рад, если бы ты это делал в Gearbox.

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

Как вам кажется, журналисты часто перестают писать об играх и уходят работать в пиар или маркетинг?

Да, это самое распространенное. Могу сказать за авторов, которых я нанимал в ShackNews. Где-то 60% из них сейчас работают в игровых компаниях: Zenimax, Activision, Ubisoft, Gearbox, несколько инди вот эта компания, которая сделала Firewatch, забыл название. В общем, да, это происходило регулярно, по крайней мере, когда я работал в журналистике. Потому что раньше индустрия была гораздо меньше. Было вот как: если вы влюблены в видеоигры, то просто ищете открытую дверь, и вы на работе. Сейчас все стало более специализированным и журналистика, и геймдев. Сейчас быть эффективным игровым сценаристом это не просто писать, а иметь техническое представление, как быть эффективным. Сколько будет стоить показать на экране то, что вы написали? Это относится и к сценаристам кино или сериалов, но и к игровым сценаристам. Нужно понимать, как перевести сценарий в доллары, чтобы это появилось на экране.

Мы уже говорили, как изменился маркетинг игр. А как думаете, за эти 10 лет игровая журналистика изменилась? И если да, то как?

Да. Я думаю, она изменилась к лучшему. Раньше во всех изданиях мира вроде Entertainment Weekly работали фанаты, так что было мало критики. Все тексты были такие: Вот новая крутая штука, она тебе понравится. Это видеоигры! Не могу поверить, что они у нас есть!. Вот так все было двадцать лет назад. Мы называли это шелухой. Было интересно, весело, но, знаете, несерьезно и по-детски. Ведь не каждая игра хорошая.

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

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

И вдобавок ко всему традиционные игровые издания теряют читателей, которые уходят к стримерам. Они видят, что трафик падает, а скандальные заголовки приносят деньги. Что они будут делать? Больше скандалов, потому что это хотя бы позволит им удержать аудиторию. Это приносит вред нашей индустрии, когда скандал делают из всего, даже без причины. Это не помогает. Это грустно. Хотя так происходит не со всеми, но встречается все чаще.

А стримеры просто говорят: Ребята, у меня новая игра, зацените!. Хотя им иногда платят, чтобы сказать, что игра крутая, а покупатели еще не вполне поняли, что стримеры могут играть в игру и притворяться, что им нравится. Иногда и не нравится, они просто делают вид.

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

Именно. И покупатели этого пока не поняли. Часто стример будет играть и говорить, что ему нравится, но не будет до конца честным с вами. А правила пока не ясны: какие-то стримеры честно говорят про рекламу, какие-то молчат. То есть некоторые честнее других расскажут, нравится ли им игра. Так что да, мы снова вернулись в мир, когда медиа получает деньги от разработчиков и издателей.

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

Давайте поговорим про игровую индустрию в целом. Это был тот еще год, и надеюсь, следующий год будет лучше он уже на носу. Думаете, если сложить все, то этот год был, скажем так, положительным или отрицательным?

Ох, блин. Очень сложно это разделить. Нужно иметь в виду, что людям просто повезло пережить этот год не всем, и это правда.

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

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

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

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

Какие игры им купить?


Ну да, игры или что-то близкое к ним.


Ох, боже мой. Ну, если у вас семья, то, если честно, Nintendo обставляет всех. Я с радостью рекомендую купить Nintendo Switch и пару джойконов. Поиграйте с друзьями или семьей. На платформе много крутых игр, включая Borderlands. Хотя в нее, наверное, не стоит играть с шестилетним ребенком.

Это очень мне нравится. И если вам повезло купить PlayStation 5, то купите GodFall она очень интересная, и мы добавляем контент каждый день. Я бы ее с радостью рекомендовал, так как сам много в нее играл. Если подумать о ПК, то в GodFall можно поиграть и там. Но если ищите недорогого удовольствия, то Among Us стоит несколько долларов, и она очень весёлая. Стоит копейки. Я бы ее посоветовал может быть надолго ее не хватит, но свою цену она полностью отрабатывает.

Да и, пожалуй, все. Вот игры, в которые можно поиграть с друзьями, семьей и немного хардкорного ПК-гейминга, и немного казуального. А еще купите инди, их всегда много на скидках.

И не забудьте купить GodFall.


Естественно!


Спасибо, что пришли. Спасибо за разговор, было очень весело, интересно и, надеюсь, познавательно.

Спасибо вам!


Всем до свидания.

Завтра, в 20:00 в наших соцсетях выступить Слава Савицский Senior Android Developer в Spotify. Слава уже много лет работает в шведском офисе компании и запускал облегченную версию Spotify Spotify Lite для стареньких версий андроидов, которые очень популярны на развивающихся рынках.

Cлава расскажет о том, как проходит собеседование в Spotify, немного про разработку Spotify Lite и ответит на ваши вопросы об Android-разработке.

О чем пойдет речь на эфире

• Как попасть на работу в Spotify: что писать и не писать в резюме, как проходит собеседование
• Культура Spotify: как устроены и работают команды
• Жизнь айтишника в Швеции: плюсы и минусы

Spotify Lite совершенно новая, облегченная версия приложения под Android

• Как возникла необходимость создать легкую версию Spotify
• Путешествие для исследования условий, в которых должен будет работать Spotify Lite: как андроид-разработчики ездили в Азию, чтобы тестировать андроиды, качество интернета, как проходили сами тесты
• Что такое Spotify experience то самое главное качество, за которое пользователи выбирают именно Spotify и как его сохраняли в Lite-версии
• Как технические решения Spotlfy Lite помогли основному приложению

Про тулы для профилирования в андроид-разработке

• Тулы для профилирования скорости: Performance Analyzer в Android Studio, Zero overhead, Uber nanoscope, Perfetto
• Профилирование памяти: Android Studio, Memory Analyzer Tool в Еclipse
• Профилирование размера приоложения: Apk Analyzer в Android Studio, и есть command line tools в Android SDK

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

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

Завтра, в 20:00 у нас выступит Михаил Веселов полиграфолог с 10-летним стажем. Миша выступал экспертом и делал допрос для нашей игры с детектором лжи, которая прошла в декабре.

Миша провел более 3500 допросов. за 10 лет. Кроме этого Миша работает тренером помогает людям пройти проверку на детекторе, чтобы устроиться на работу, и уже обучил более 400 человек.

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

Тезисы выступления

• Как Миша пришел в профессию
• Почему в корпоративной среде полиграф используется чаще, чем в силовых структурах
• Насколько часто айтишников просят пройти допрос на полиграфе и какие вопросы задают
• Внутренние расследования в корпорациях
• Может ли сильное волнение показать вас виноватым на полиграфе, если вы на самом деле ничего плохого не делали?
• Как именно пройти полиграф с нужным результатом: теория
• Как проходят тренировки на прохождение полиграфа
• Почему надо готовиться к каждому отдельному допросу
• Можно ли в целом натренироваться проходить любой допрос
• Насколько эффективен метод: можно ли спалить, что человек готовился к допросу
• Сколько времени занимает тренировка и сколько это стоит
• Почему Миша регулярно играет в Мафию и как играть, чтобы научиться ловить людей на лжи

Как не пропустить эфир?

Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.

До встречи в эфире!

В прошлый вторник у нас выступал Михаил Веселов полиграфолог со стажем в 10 лет. Миша провел более 3000 допросов и обучил почти 400 человек проходить проверки на детекторе лжи.

Это уже не первый спикер со специализацией, которую на Хабре недолюбливают: например, летом выступал Вячеслав Дреер, монетизатор мобильных игр и обсуждение под его выступлением растянулось почти на 150 комментариев.

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

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

---

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

Q: почему именно уголовный розыск, как туда пришли?

Часто после армии люди, привыкшие находиться в военизированной, корпоративной среде, решают не слишком менять свою обстановку. Так, как я, поступали многие люди, которые служили. Надо упомянуть, что в армии я служил в 1995-97 годах как вы сами понимаете, тогда в стране была очень напряженная криминальная обстановка. Наблюдая за этим, я, дослуживая последний год, решил поработать в правоохранительных органах и внести посильный вклад в борьбу с преступностью. Я считаю, что в этом плане я преуспел. Довольно много торговцев наркотиками и ворюг с моей подачи попали в суд и далее. Я этим горжусь и не боюсь этого, всегда с удовольствием говорю, что я мент по жизни. В общем-то, сложившейся у меня судьбой я доволен.

После работы в милиции я решил, через какое-то время, выбрать новую профессию; не стал досиживать до пенсии как говорится, до седых висков. Стал полиграфологом. Закончил курсы, купил оборудование и начал деятельность. Сначала использовал свои связи в правоохранительной системе, через какое-то время создал себе сайт, стал использовать социальные сети. Узнал, что такое SEO-оптимизация, Яндекс.директ и Google-реклама, начал продвигать свою деятельность везде, распространять свои услуги.

Через какое-то время интересная бизнес-модель постучалась ко мне в дверь. Люди стали обращаться, интересоваться предварительными консультациями. Они хотели получить информацию о самом процессе опроса на компьютерном полиграфе; хотели узнать, как правильно пройти, чтобы не завалить тест. Как вы понимаете, эти люди были как из силовых структур, так и из коммерческих организаций.

Q: почему в корпоративной среде чаще, чем в силовых структурах, используются полиграфы?

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

Если человек отказывается проходить проверку, то у него могут сложиться определенные проблемы, особенно в продвижении по карьерной лестнице наверх (хотя проверка и считается добровольной).

Q: насколько часто айтишников просят пройти опрос на компьютерном полиграфе?

Уже начали каждые года 2-3 звать IT-специалистов и специалистов по информационной безопасности если в компании есть такие подразделения на опрос с компьютерным полиграфом.

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

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

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

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

Конечно, такой подход используют не все компании, но в последнее время ко мне стало обращаться все больше людей из IT-сферы. Мой тренинг персональный, подразумевает конфиденциальность. Люди, которые хотят получить мою консультацию, хорошо понимают, что я у них не буду спрашивать, кто именно их работодатель; это не мое дело, это мне не нужно, но сферу деятельности я всегда спрашиваю. Это обязательно, потому что сфера деятельности определяет, что именно человеку предложат во время испытания. Варианты вопросов, которые будут задаваться, то, что будут у него спрашивать; самое интересное в этом. Функционал и сфера деятельности человека определяет, какую модель ему предложат как при приеме на работу, так и при плановой проверке.

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

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

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

Мотив и заинтересованность это важно. Если у человека нет мотива и заинтересованности, то предъявлять ему такие подозрения, конечно, можно, но надо все делать осторожно. Все-таки люди, работающие в IT это специалисты. Если их обидеть, то у них может появиться тот самый мотив на нанесение вреда компании, и можно понести убытки в сотни миллионов. Я всегда говорю об этом заказчикам: нужно быть очень аккуратным, внимательным, выборочным. Если вы не умеете предлагать испытание на полиграфе людям этой профессии, то лучше делегируйте это мне.

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

Если подытожить: специалисты из IT-сферы могут встретиться с полиграфом при приеме на работу, во время плановых проверок работодателя, а также в случае, если происходит инцидент и очерчивается круг подозреваемых, куда попадают люди. Тогда используется психодиагностика и соответствующий специалист.

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

Мой формат это антиполиграф-тренинг. Достаточно интересное мероприятие, которое поможет вам, если вы заинтересуетесь, всегда проходить полиграф. Что надо делать, как разговаривать. Это смесь практикума и психотерапевтического подхода. В этом подходе я использую также гештальт-терапию, через которую я формирую отличную, убедительную аргументацию у моих испытуемых. На любые вопросы, даже сложные, даже в случае, если их провоцируют и некорректно с ними разговаривают, они умеют отвечать.

Q: может ли сильное волнение сделать вас виновным для полиграфа, если вы ничего плохого не делали?

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

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

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

Например, человеку из закупок задают вопрос на плановой проверке: Получали ли вы дополнительное вознаграждение при работе с поставщиком? А он, допустим, получал. И этот вопрос вызывает достаточно серьезный стресс, даже гиперстресс. Человек в своей стратегии будет отрицать подобное, но когнитивный диссонанс, скорее всего, произойдет и вызовет еще больше стресса.

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

И в масштабе стран у американцев, у израильтян, у нас, в Турции, в странах Южной Америки везде также есть свои методы работы с полиграфом. Успех всегда зависит от опыта специалиста.

Итак, как именно пройти полиграф с нужным результатом? Я думаю, если человек этого очень сильно хочет, то ему надо получить глубинную информацию, с нюансами. Потому что теорию прочитать, заказать много книг по этому делу это хорошо. Но, если у него нет практического навыка проведения таких процедур, исследований, то ему будет сложно разобраться. В этом деле большое значение имеет практика. Я в этой профессии уже 11-й год, и я скажу так: каждый раз я что-то новое узнаю, каждый раз что-то по-новому происходит. Я всегда готов встретить новую ситуацию, которой раньше не было. Хотя в последнее время я ничего особенно новенького не встречал; все люди вроде бы разные, а ситуации и поведение очень похожи. Хотя все на полиграфе дают неодинаковые реакции, конечно.

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

Q: как проходят тренировки перед полиграфом?

Очно, конфиденциально, персонально. Я не собираю залы и группы, я работаю конфиденциально для отдельного человека. Вообще, моя деятельность не подразумевает, что я нарушаю какой-то закон. Я себя позиционирую так: я готовлю человека к экзамену. Испытание на полиграфе это своего рода экзамен, и к нему надо готовиться. Если не подготовиться к экзамену, то вспоминаем студенческие времена мы не сдадим экзамен.

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

Но в испытании на полиграфе все сложнее, конечно. Груз ответственности над человеком висит: он может не получить работу, он может потерять работу. А если служебное расследование его сделает виноватым, то он не только потеряет работу, но и приобретет негативный образ в будущем; его работодатель будет распространять этот образ, и это может обнулить дальнейшую деятельность для человека, привести к тому, что придется менять сферу деятельности. Или шифроваться сильно. Возможно, даже фамилию и имя менять, чтобы стереть информацию о том, что ты очень плохо постарался, совершил нечистоплотный поступок, а работодатель об этом узнал и тебя не только уволили по статье, но и следующим работодателям сообщают. Понимаете, какая опасность? Я всегда говорю, что нечистоплотные поступки не стоит совершать. Если вы недовольны тем, как с вами обращается работодатель активируйте свое резюме повсюду (HH, Superjob и так далее) и ищите нового. IT-сфера сейчас самая высокооплачиваемая на рынке труда я за ним слежу.

Q: почему надо готовиться к каждому отдельному опросу?

Опрос он индивидуальный. Например, при приеме на работу используется достаточно лайтовый формат опроса. Если это плановая проверка, и функционал человека пока неизвестен, то надо определенно готовиться. Кто он? Из IT-сферы, но он оператор каких-то систем, или начальник отдела или управления? А если он в управлении, то как он участвует в разработках, взаимодействует с подрядными организациями? Надо очень внимательно разобрать, что ему могут предложить. Каждое тестирование это вещь, к которой стоит подготовиться, если человек не знает, как этим заниматься.

Q: есть ли возможность задать на полиграфе вопрос, который имеет более сложный ответ, чем да/нет, и получить достоверный ответ?

Нет, во время испытаний на полиграфе испытуемый отвечает только да/нет. Бинарно, по-другому никак. Полиграфолог перед тестированием сориентирует и скажет, что во время тестирования может быть только два варианта ответа. Если испытуемый скажет не знаю, не могу полиграфолог его поправит и попросит дать бинарный ответ. С ним не надо спорить. Если вы будете спорить и отстаивать какую-то точку зрения, и еще будет какая-то агрессия, эскалация до этого лучше не доводить. Если это произошло вы, считайте, провалили полиграф. Полиграфолог не будет отвечать на агрессию и говорить плохие слова он улыбнется и запишет негативное заключение, и все. Это заключение прочитает HR-специалист, который принимает в компанию, или шеф безопасности, который на совещании с другими руководителями скажет: этот человек протестирован, по ряду вопросов не подходит, рекомендовано предложить ему покинуть компанию. Собственно, я сам выполнял обе эти роли. Когда я работал специалистом-полиграфологом, мне доводилось писать негативные заключения для шефа безопасности, а теперь, когда я сам, например, шеф безопасности в организации, я получаю их и говорю о них на совещании.

Q: можно ли в целом натренироваться проходить любой опрос?
Конечно, можно натренироваться. Самое главное это подбить аргументацию. Если ты знаешь контекст ситуации, ты всегда можешь аргументативно правильно формировать образы и реальность при помощи своей аргументации. Это сложный навык.

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

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

Q: насколько эффективен метод, можно ли спалить, что человек готовился к опросу?
Хороший вопрос. Полиграфолог может понять скорее, не то, что человек имеет подготовку, а то, что он противодействует на полиграфе. Он может это заметить. Есть люди, которые используют какие-то подходы в противодействии, которые они где-то почерпнули, прочитали в интернете, увидели; такие попытки, как правило, заканчиваются провалом. Здесь нужна более глубокая подготовка. Я на своем тренинге запрещаю людям так делать. Методов противодействия, глупых методов, очень много, их легко найти в интернете, но ни один из них не помогает. Они всегда приводят к провалу тестирования. Если вас спалили на противодействии это всегда негативное заключение.

Но вот после моего практикума это практически невозможно сделать, если, конечно, человек сам не расскажет, что имеет подготовку. Либо утечка может произойти от меня, но не в моих целях (правилах, задачах, интересах) сливать клиентов. Это абсолютная глупость для человека, который работает на таком специализированном рынке. Я свою репутацию сильно берегу и люблю её.

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

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

Q: сколько времени занимает тренировка, и сколько это стоит?
Хороший вопрос. Моя тренировка, мой тренинг и практикум он однодневный, занимает он шесть часов. За шесть часов я закрепляю навык, и человек может сам в этом убедиться: в моем тренинге есть несколько тестирований, в начале и в конце. В конце человек понимает, что он освоил этот метод.

К ценообразованию у меня дифференцированный подход. Зависит от управленческого статуса человека, социального положения. Я приведу примерную градацию. Подготовка при приеме на работу: если человек идет устраиваться, ему предложили полиграф, и он хочет подготовиться за это я беру 50 тысяч рублей. Если подготовка связана с плановой проверкой, то моя премия составит 75 тысяч. Если это внутреннее расследование, ситуация сложная, и человек, возможно, даже косвенно замешан, или у него какие-то другие опасения касательно этого расследования, то ценник может составлять более 100 тысяч. Вот такая у меня политика. Опять же, большое значение имеет ситуация, социальный статус и управленческий уровень. На это я всегда обращаю внимание.

Конечно, можно подумать, что в таком случае человек, возглавляющий IT-департамент, захочет прикинуться обычным оператором, но это будет крайне сложно для него. Я все-таки занимаюсь психодиагностикой. Управленческий уровень я могу определить, просто пообщавшись с человеком. Скрыть это крайне сложно. Манера общения, лексикон; даже если человек попытается быть более простым, чем он есть на самом деле, я все равно это пойму. Это профессиональное. Чувствовать людей и понимать, из какой они сферы и на каком управленческом уровне они находятся это моя работа.

Q: почему вы играете в мафию?
Я упоминал, что часто посещаю профессиональный клуб игроков в психологическую ролевую игру мафия. Это подкрепляет мою работу; мафия это психодиагностика в чистом виде, причем в игровом формате.

Научиться определять, когда люди врут в игровом формате, гораздо сложнее, чем в жизни и, соответственно, врать в игре гораздо проще. Я об этом часто рассказываю, когда посещаю клуб; все удивляются как же это так.

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

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

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

Q: как проходят тренинги?

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

Я могу сказать, что у меня действительно полиграф проходят все. Бывает один нюанс: мы все сделали, подготовились с человеком, но потом человека не зовут на работу, не хотят с ним заключать контракт, хотя до этого уже высылали оффер. Есть такие случаи. Все этапы собеседования у человека пройдены, полиграф тоже пройден, но работодатель не дает обратной связи, и повисает пауза. Почему так никто не знает. Скорее всего, в таком случае работодатель мог переобуться в отношении вашей персоны, взять паузу, или необходимость в позиции отпала.

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

Поэтому моя тренировка связана с несколькими тестированиями; практический навык сидения в проводах, на датчиках это тоже своего рода опыт. После тренировки, когда опыт получен, страхи и тревоги на 50% пропадают только благодаря опыту. Уверенность и силу мы приобретаем только тогда, когда получаем опыт. В этой жизни все так. Теория хороша, когда она подкреплена опытом. Я специалист, целенаправленно выбрал эту сторону луны, и готовлю людей к прохождению таких испытаний.

С каждый годом я фиксирую, что полиграфы все больше и больше применяются у нас. Этой диагностикой очень многие стали пользоваться. Что-то произошло работодатель сразу отправляет на полиграф.

Q: а кого они хотят поймать?
На самом деле, работодатель не хочет никого поймать, он такую особую цель не преследует.

Полиграф создает определенную реальность в головах людей, которые слышат, что в организации есть полиграф. При помощи полиграфных испытаний учредитель или глава компании (или гендиректор, главный бенефициар в общем, человек, который в этой компании держит руку на пульсе и управляет ею) усиливает контроль. То есть, если в организации работает три тысячи человек, и в один день они узнают, что в организации будет полиграф, то они сразу все в тонусе. Они ждут этого полиграфа когда будет процедура, кому предложат, как это все будет выгладить? Правового аспекта не будем касаться: у нас полиграф считается добровольной психодиагностикой.

То есть, если соглашаетесь хорошо, если нет никто не имеет права насильно заставлять; конечно, глубинная структура этого процесса предполагает, что, если вы отказываетесь, то с вами надо поговорить. То есть почему это вы отказываетесь, 99 человек согласилось, а вы что, какие у вас причины? Надо будет некие веские причины объяснить. Если вы в такой ситуации будете кричать и бить себя пяткой в грудь, что вы самый честный и вас унижает такое недоверие, то это может закончиться плачевно для вашей карьеры.

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

Я не смещаю фокус, но просто предлагаю вам задуматься. Все-таки мы живем в мире, где почти везде существует иерархия. Корпорации, силовые структуры, страны, группы, содружества, сообщества. Даже какое-нибудь племя в амазонской сельве, у которого нет государственности, имеет управленческую иерархию и пошатнувший авторитет вождя будет убит и съеден. Мы, конечно, цивилизованные люди и никого не съедим; но, когда появляется человек, который пытается раскачать управление, нарушить дисциплинарные правила, то от него обычно принято избавляться. Потому что он угрожает всей пирамиде управления. И, если эта угроза будет заражать всех остальных, то наступит хаос. И тогда государство, организация, сообщество падет. Конечно, на их месте может вырасти что-то новое, но все новое снова должно будет иметь структуру и уровни управления. Это человеческий феномен, и в таком сообществе мы живем. Наша цивилизация пронизана иерархиями, которые создают наше общество, наши организации и страны. Насколько устойчива эта пирамида, настолько и будет возможно процветать и получать определенную выгоду в этом мире.

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

Это важно. Поэтому отказ от полиграфа это нелояльный ход любого сотрудника любого уровня управления.

Q: кому не предлагают пройти полиграф?

Полиграф не предлагают председателю совета директоров, генеральным директорам, учредителям. То есть, тем людям, которые сами назначают полиграф и предлагают это делать службе безопасности или HR-подразделению. Собственно, полиграфолог, если он присутствует в организации, работает либо в безопасности (чаще всего), либо в кадрах.

Q: если вы принимаете безналичные платежи, то ваш список клиентов все равно утечет

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

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

Q: зачем нужен датчик под ножками стула?

Хороший вопрос. Датчик под ножками стула это датчик движений, вибраций или тремора (это одно и то же). Он может выглядеть по-разному, в зависимости от производителя оборудования. У нас производителей около четырех или пяти, и во всех российских полиграфах датчик движения есть. Это хорошая инновация, введенная в полиграф нашими разработчиками; такой датчик необходим.

Вы сидите на стуле, и вся вибрация передается стулу, а от стула передается на датчик. Как вариант, датчик может выглядеть как коврик, и тогда вы будете сидеть на нем. Или как круглые металлические блины, которые кладут под каждое бедро. Датчик помогает специалисту моей профессии определить скрытые мышечные напряжения, движения или действия, связанные с причинением себе скрытно боли.

Завтра, в 20:00 в наших соцсетях выступит Валерия Коган выпускница физтеха, со-основательница стартапов Fermata и Smartomica.

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

В 2019-ом компания привлекла $1,1 млн инвестиций от частного инвестора, а уже в в марте 2020-го, в ходе раунда А получила еще $3,7 млн. инвестиций от британского фонда Massa Innovations и нескольких частных инвесторов.

Кроме агротеха, Лера занимается разработкой новых методов диагностики рака и является приглашенным ученым в Roswell Park Cancer Institute. В Smartomica они разрабатывает технологии анализа медицинских и научных данных для диагностики и лечения онкологических пациентов

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

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

Тезисы выступления

• Как в Fermata следят за растениями
• Почему лучше выращивать марихуану, а не помидоры
• Как пожухлый салат может привести фермера к разорению
• Почему для эффективного сельского хозяйстве недостаточно людей
• Почему и как Fermata стала первопроходцем в умных теплицах
• Как в Fermata собрала десятки тысяч фотографий помидоров для машинного обучения
• Как фермеры и агрономы помогали собирать разметку данных
• Что за датчики используются в теплицах, что можно измерять и контролировать через ML и как это влияет на здоровье растения
• Как устроена работа в теплице, за какими параметрами надо следить
• Какие задачи остаются за человеком в умных теплицах
• Какие задачи стоят перед R&D отделом Fermata
• Как на основе визуального анализа узнать состав растения
• Почему Fermata работает с теплицами и как дроны помогают выращивать растения
• Как Лера начала заниматься анализом генетических данных и помогать онкологам бороться с раком
• Как одна команда одновременно работает и над агротехом и над онкологией

До встречи в эфире!

ЗАВТРА, в 20:00 в наших соцсетях выступит Омар Ганиев, основатель компании DeteAct
и член российской команды хакеров LCBC. Омара можно смело назвать одним из самых лучших хакеров страны.

LCBC заняла первое место в финале международного турнира по компьютерной безопасности 0CTF в Шанхае в 2016 году.

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

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

Сейчас команда More Smoked Leet Chicken, членом которой является Омар, состоит из энтузиастов, работающих в разных компаниях и странах, и это сильнейшая в России и одна из сильнейших в мире CTF-команд.

Что касается компании DeteAct (официально ООО Непрерывные технологии), то она предоставляет услуги по анализу защищённости и тестированию на проникновение. Проще говоря, различные компании просят ребят взломать их системы для того, чтобы проверить их на прочность и узнать, как не допустить вредоносные хакерские атаки и потери для бизнеса.

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

План выступления

Задавайте вопросы в комментариях и Омар ответит на них во время прямого эфира.

• Чем занимаются хакеры, работающие в легальном поле, Что такое пентест, и кто его заказывает?
• Насколько это сложная работа, и как проверить её качество?
• Можно ли прожить в сети, не проверяя свою защищённость?
• Какие уязвимости чаще всего можно обнаружить в софте и инфраструктурах компаний?

До встречи в эфире!

На этой неделе в наших соцсетях выступал Омар Ганиев, основатель компании DeteAct
и член российской команды хакеров LCBC. Омара можно смело назвать одним из самых лучших хакеров страны.

LCBC заняла первое место в финале международного турнира по компьютерной безопасности 0CTF в Шанхае в 2016 году.

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

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

Сейчас команда More Smoked Leet Chicken, членом которой является Омар, состоит из энтузиастов, работающих в разных компаниях и странах, и это сильнейшая в России и одна из сильнейших в мире CTF-команд.

Что касается компании DeteAct (официально ООО Непрерывные технологии), то она предоставляет услуги по анализу защищённости и тестированию на проникновение. Проще говоря, различные компании просят ребят взломать их системы для того, чтобы проверить их на прочность и узнать, как не допустить вредоносные хакерские атаки и потери для бизнеса.

Делимся с вами записью и расшифровкой эфира.

---

Всем привет, меня зовут Омар Ганиев. Также я известен под никнеймом beched в хакерской среде. Я хакер, много лет занимаюсь проверкой безопасности компьютерных систем. Это стало для меня хобби еще в школе, а последние 9 лет это моя основная профессия. Последние 7 лет я работаю в стартапах в сфере информационной безопасности, сам являюсь основателем компании DeteAct, она же Непрерывные технологии. Сейчас нас 10 человек, мы хорошо растем и предоставляем услуги в области практической информационной безопасности. Тестирование на проникновение, анализ защищенности, прочие разновидности аудитов безопасности обо всем этом мы поговорим сегодня.

Пентест, тестирование на проникновение. Надо определиться, что это такое, потому что даже в сфере информационной безопасности, среди тех, кто пентестами и аудитами занимается, часто возникает путаница и непонимание терминологии. Часто оказывается, что разные люди под пентестом подразумевают разные вещи; особенно неприятно, когда эти люди заказчик и исполнитель услуг. Основные термины здесь аудит безопасности, тестирование на проникновение (penetration test, пентест), анализ защищенности (security assessment) и редтиминг (red team).

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

Пентест (тестирование на проникновение) это намного более конкретная штука, хотя и она может быть понята по-разному. Немедленная логическая ассоциация заключается в том, что пентест это проверка на то, можно ли проникнуть в какую-то систему, и результатом пентеста должен быть бинарный ответ да/нет: получилось ли проникнуть, или нет. Это одно из пониманий этой услуги то есть, проверяется, сможет ли потенциальный атакующий проникнуть в систему, добиться каких-то целей, допустим, за неделю или за две недели. В течение этого времени пентестеры пытаются ломать систему, и таким образом можно проверить уровень защищенности системы. Особенно это актуально в сфере комплаенса. Некоторые организации государственные организации, международные платежные системы могут требовать от компаний (банков, карточных эквайрингов) прохождения пентеста именно в таком смысле. Такой пентест должен проверить, получилось ли да или нет получить доступ к платежным данным. Если нет, то все нормально; если да, то все плохо.

Но есть и другое понимание пентеста, которое часто называют анализом защищенности. Это работа вширь: хакеры-пентестеры, вместо того, чтобы пытаться вглубь проникнуть к ресурсам, ищут как можно большее количество уязвимостей вширь. Чаще всего, все-таки, заказчики хотят видеть именно эту услугу. Им интересно не просто получить ответ (поломали или не поломали), а найти как можно больше дыр, чтобы закрыть их чтобы их в дальнейшем не поломали.
Редтиминг это похоже по значению на то, как работает пентест в смысле проникновения, но с некоторыми особенностями. Вообще, на тему того, что же такое редтиминг, ведется больше всего холиваров. Если кратко это такое мероприятие, при котором атакующая команда ставит своей целью нанесение определенного ущерба, достижение некоторых угроз или бизнес-рисков например, хищение средств, баз данных клиентов, почты руководителя (для каждой компании свой бизнес-риск, кому что критично). Перед командой атакующих практически не ставится ограничений (единственное ограничение рамки закона). В отличие от обычного анализа защищенности или пентеста, редтимеры могут достигать бизнес-рисков любыми методами: хоть проникнуть в офис и физически украсть бумагу с паролями или перехватить wifi. Защищающаяся сторона то есть, компания, которую тестируют тоже не ограничена. Безопасники, администраторы, разработчики, devops-ы сопротивляются этому тестированию, пытаются выявить атаки и предотвратить их. Таким образом, получается реалистичная тренировка и моделирование реальной ситуации. Учения, можно сказать.

Q: ради интереса: в каких странах более востребованы пентестеры, и откуда больше всего поступает заказов на проверку?

Самый широкий спрос на пентесты в США. Если второй вопрос по российским компаниям, то к ним больше всего заказов поступает именно из России. Этот рынок достаточно изолирован в каждой стране, сам по себе. Все стремятся заказывать такие услуги у тех, кого они знают, потому что это щепетильный вопрос; никто не хочет доверять свою безопасность кому-то из другой страны или незнакомому. С Запада, тем более, почти никто не будет заказывать такие услуги из России из-за санкций и плохой репутации.

Итак, мы примерно разобрались в пентесте и его разновидностях. Можно рассказать вкратце о том, как ведутся проекты и какая здесь методология. Тут надо сразу разделить методику проведения работ на так называемые ящики разного цвета. Можно проводить пентест в режиме blackbox (черный ящик) тестировщикам не выдается почти никакой информации об объекте исследования, кроме адреса сайта (или даже названия компании). Другая крайность whitebox (белый ящик), когда выдается вся информация. Если это инфраструктура, то выдаются все IP-адреса, схема сети, доступ во внутреннюю сеть (если необходимо), все hostname (доменные имена). Если это ПО, какой-нибудь веб-сервис, то выдаются исходные тексты, конфигурация, учетные записи с разными ролями и так далее. Наиболее распространенный режим greybox (серый ящик), это может быть что угодно в спектре от черного до белого. Какая-то информация выдается, но не вся. Например, для веб-сервиса могут быть выданы учетные записи с разными ролями, какая-то базовая информация о технологическом стеке: используемые языки программирования и базы данных, схема инфраструктуры сервиса. Но при этом не выдаются исходники.

После того, как определились с методологией, с режимом проведения работ, атакующей стороне даются вводные данные. То есть, если необходимо, выдаются доступы, адреса хостов и т.д. Атакующая сторона может выдать свои IP-адреса, с которых будут проводиться атаки, чтобы заказчик отличал их от реальных злоумышленников. Далее проводятся классические шаги пентестов; конкретная реализация и разбивка может отличаться, но, в целом, в начале должна быть проведена разведка. Пентестеры ищут точки входа в инфраструктуру хосты, сетевые сервисы, email-адреса. Если это web-сервис, то ищут API Endpoints различные web-интерфейсы, различные хосты API под домены и так далее. После того, как проведена разведка, наступает этап сканирования (phasing), когда проводится поиск уязвимостей в найденных интерфейсах. Когда уязвимости обнаружены, следующий этап эксплуатация: уязвимости используются, чтобы получить какой-то доступ. Дальше, в зависимости от того, какой это пентест, может проводиться постэксплуатация: продвижение вглубь системы и получение дополнительных доступов. Дальше может быть зачистка. Заказчик не всегда хочет, чтобы проводилась дальнейшая эксплуатация: иногда достаточно просто найти уязвимость и отрепортить ее.

Для того, чтобы было понятнее, что значит постэксплуатация: допустим, пентестеры нашли уязвимый сервер в инфраструктуре, доступный извне. Скажем, недавно вышли патчи для уязвимости в MS Exchange почтового сервера Microsoft, который почти у всех корпоратов стоит и торчит наружу. В нем обнаружилась критическая уязвимость. Эта уязвимость сама по себе дает огромный эффект: атакующие могут с ее помощью получить доступ к почте. Но, помимо этого, они могут осуществить постэксплуатацию и с этого почтового сервера дальше распространяться по инфраструктуре. Захватить какие-то еще серверы, инфраструктуру домена Windows Active Directory, попасть на рабочие станции сотрудников то есть, в инфраструктуру разработки. И так далее.

Q: какие минимальные вводные данные требуются от организации для пентеста и для аудита?


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

Q: а в РФ есть реальные редтимеры с локпиком и кувалдами? :D

Я думаю, что такие навыки много у кого есть. Насколько востребованы такие проекты и насколько часто они выполняются я, если честно, не знаю. Чтобы требовалось прямо с отмычками ходить и перелезать через заборы. Наверно, такие проекты редко проводятся.
Q: как вы обходите Web Application Firewall или хотя бы Windows Defender? Что можете сказать про фреймворки Empire и Koadic, пользуетесь ли ими?

WAF мы обходим вручную, подбирая подходящий payload. Тут методики стандартные. Единственная сложность с WAF если это редтим, когда защищающаяся сторона препятствует атакам если мы свою атаку как-то спалим, или нас обнаружат при помощи каких-то средств защиты типа WAF, то нам могут прикрыть уязвимость. Поэтому нужно действовать аккуратно и проверять payload (т.е. свой эксплоит) на каких-то других хостах, где нет уязвимости. Таким образом, WAF получится проверить и обойти, но попутно не будет обнаружена уязвимость защищающейся стороной.

Q: какой софт нужен для атакующих и для защиты?

Какой софт нужен для защиты это огромная тема. Она намного шире, чем пентест. Какой софт нужен для атакующих это хороший вопрос, потому что это зависит от того, о каких работах мы говорим. Если мы говорим об анализе ПО, web-сервисов, то практически никакое ПО не требуется. Достаточно такого швейцарского ножа, как инструмент Burp Suite. Платная версия стоит $400 и содержит практически все необходимые инструменты. Плюс, конечно, любой рабочий язык программирования обычно у пентестеров это Python или GoLang. Этого достаточно.
Если говорить об инфраструктуре, о редтиминге там инструментарий гораздо шире. Нужны разнообразные сканеры уязвимостей, нужны инструменты для закрепления на системах: после того, как мы проломились в какую-то систему, нужно в ней закрепиться, нужно обфусцировать свой payload, чтобы он не был обнаружен антивирусом, и так далее.

Q: какие сферы в РФ больше всего просят отпентестить или провести аудит?

Видимо, речь про то, в каких индустриях наибольший спрос на пентест. Очевидно, что он нужен тем компаниям, в которых есть IT; чем более развито IT, чем это более IT-шная компания, тем больше нужен пентест. Примерно спрос этому соответствует. Для некоторых компаний пентест обязателен, потому что они являются частью критической информационной инфраструктуры: государственные предприятия и банки. Для банков пентест нужен по требованию Центробанка, и еще в рамках получения сертификата PCI DSS для международных платежных систем. Этот сертификат нужен и другим платежным организациям. То есть, платежные организации, субъекты критической информационной инфраструктуры и IT-компании требуют пентестов. То есть, любые IT-компании, включая стартапы, у которых вся инфраструктура это web-сервис с базой пользователей: для них критично, если их поломают.

Q: насколько важно понимание социальной инженерии при пентесте?

Я отдельно не упоминал ее. Я бы сказал, что это один из инструментов редтиминга; кроме того, зачастую социальная инженерия проводится отдельно, как отдельная услуга, и выглядит как простая рассылка. Мы делаем фишинговый сайт, ищем email сотрудников компании и рассылаем по ним ссылку на этот сайт с какой-нибудь легендой (например, это новый корпоративный портал, нужно всем обязательно зайти и ввести свой пароль).

Затем ведем статистику сколько человек просмотрело письмо, кликнуло на ссылку и ввело пароль. Показываем ее заказчику, и он понимает, с кем нужно проводить ликбез. Честно говоря, практически никаких навыков для такого тестирования не требуется, и компания сама способна легко провести его с помощью open source-инструментов, если речь идет про разовую рассылку. В целом, есть целый отдельный бизнес индустрия security awareness, повышение осведомленности людей в области информационной безопасности.

Есть специальные продукты, которые регулярно рассылают фишинговые письма по базе пользователей. Если человек повелся, то ему придет обучающее видео или другой интерактивный урок, который он должен будет пройти. А потом его еще раз проверят, и будет отслеживаться тренд например, год назад 50% сотрудников повелись на фишинг, а теперь только 5%. Конечно, полностью избавиться от опасности фишинга почти невозможно.

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

Q: из чего складывается стоимость услуги?

Отличный вопрос, потому что никто вам не ответит на него толком.

Это очень по-разному. Обычно пентест стоит сколько, сколько может заплатить заказчик, грубо говоря. Это один из коэффициентов. Проблема в том, что даже объем работы изначально будет не детерминирован особенно, если это blackbox. Мы изначально даже толком не знаем, сколько там будет хостов, интерфейсов. Мы можем только примерно понять, какого характера эта компания, какая у нее может быть инфраструктура и сколько нам понадобиться людей и времени, и из этого можно будет прикинуть трудозатраты в человеко-неделях. Если у нас есть какой-то фреймворк ценообразования, можно умножить человеко-недели на наш коэффициент и выдать это как цену.
На самом деле, все очень варьируется; часто, особенно в больших компаниях, продажник просто находит компанию, выбивает какой-то бюджет, и дальше нужно выполнить работы в рамках этого бюджета. И тут, скорее, трудозатраты подгоняются под цену, а не наоборот.

Могу еще сказать, что в итоге поскольку у нас непрозрачный рынок с непонятным ценообразованием стоимость работ может отличаться в разы при неизменном качестве и трудозатратах. Вы можете найти пентест за 300 тысяч и за 4 миллиона рублей при одинаковом объеме работ. Часто это видно даже на тендерах: есть ТЗ, смотришь, какие есть ценники и предложения разброс бывает в 5-10 раз. При том, что качество вряд ли отличается в 5-10 раз.

Раз уж мы заговорили про качество и цену пентеста. Нужно понимать, нужен ли вашей компании пентест а, если вы пентестер, нужно понимать, как обосновать проведение пентеста и продать его компании. Тут тоже нет универсального ответа. На мой взгляд, драйверы пентеста это несколько простых вещей. Один из них это комплаенс, о чем я уже говорил: когда от организации требуется проведение пентеста, и без этого не получится осуществлять бизнес-функции, вроде приема оплаты пластиковыми картами. Это понятно.

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

Третий драйвер это страх: допустим, инцидентов еще не было, но, может быть, они были у других членов отрасли, и компания боится. Еще один драйвер, который можно рассматривать совместно с драйвером страха это новые компании, например, стартапы, которые только начали какую-то разработку. Он подумали и решили, что надо сразу провести пентест, чтобы исправить уязвимости и не допускать их в дальнейшем. Чтобы к моменту, когда сервис станет публичным и, возможно, популярным, уязвимостей уже не было. Это самый здравый подход.

Еще один драйвер, очень распространенный у стартапов это требования контрагентов. Такая разновидность комплаенса, когда вы можете осуществлять свои бизнес-функции, но ваши контрагенты хотят проверить, что вы следите за своей безопасностью. Поэтому, если вы небольшая компания, которая хочет продавать, например, крупным западным компаниям, то вам обязательно придется пройти пентест. Особенно, если вы предлагаете SaaS (software as a service) тогда отчет о пентесте потребуют непременно. Это будет у них в гайдлайнах, их юристы и безопасники просто не допустят такого подрядчика, который не проходил пентест.

Это причины, по которым компании обращаются к пентестерам, и мы проводим тесты. А вот с качеством, на самом деле, очень сложно. Я уже говорил, что в пентесте изначально не детерминирован объем работы, но и результат тоже не детерминирован. Вы можете заказать пентест за 6 миллионов рублей и получить отчет, состоящий из слов уязвимостей не нашли. Как проверить, что работа была выполнена, причем качественно? Вы не можете этого понять. Для того, чтобы это точно проверить, нужно практически провести всю эту работу заново. Вы можете пытаться мониторить логи, чтобы следить, что от пентестеров действительно шла сетевая активность, но это все сложно. А по-простому проверить качество работы невозможно.
Возможные меры, кроме слежения за активностью просить подробные отчеты о том, что делается, просить артефакты, отчеты от сканеров и прочие логи, например, от инструмента Burp. Изначально можно обсудить методологию что вообще собираются делать пентестеры. Из этого может стать ясно, что они понимают. Но все это требует навыков и знаний поэтому, если в компании нет безопасников, которые уже взаимодействовали с пентестерами и понимают эти услуги, проверить качество работ не получится.

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

Оба этих вопроса про карьеру, и тут можно поменять пентест на программирование, например. Я бы сказал, что нет никакого идеального возраста, но это такая мантра, которую все повторяют якобы, никогда не поздно. Но, конечно, если человек начнет заниматься в 10 лет, то он скорее добьется успеха и быстрее будет обучаться, чем если он начнет в 40 лет; хотя это не значит, что начинать в 40 лет бесполезно. Просто понадобится больше усилий. Во-вторых, если говорить с утилитарной точки зрения для работы в сфере пентеста, для того, чтобы стать пентестером и устроиться на работу, порог входа ниже, чем для разработки. Потому что для того, чтобы начать приносить пользу в разработке, нужно хотя бы уметь программировать и знать какие-то технологии. А для того, чтобы начать хоть что-то делать в пентесте хотя это и может быть иллюзия деятельности достаточно научиться пользоваться парой инструментов и интерпретировать результаты этой работы. Но это будет совсем базовый порог входа. Для того, чтобы действительно круто прокачаться в пентесте, потребуется уже больше усилий, чем для разработки. Для того, чтобы по-настоящему прокачаться в хакерстве, нужно знать разработку причем даже не в одном языке программирования и технологическом стеке, а в нескольких. Еще нужно хотя бы в какой-то мере (а лучше хорошо) знать инфраструктуру, сети, администрирование Windows и Linux, и программирование. Нужно глубокое погружение в какую-то сферу, и при этом еще и уметь ломать. То есть, нижний порог входа в пентесте ниже, но стать senior или выше сложнее.

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

Q: реальны ли сейчас атаки на wifi Evil Twin, или у компаний авторизации через RADIUS-сервер?

Честно говоря, не могу экспертно ответить, не обладая статистикой. Я думаю, у всех по-разному; наверняка много где прекрасно сработает Evil Twin.

Q: используете ли в своей работе методики и подходы NIST, OSSTMM, OSINT, OWASP и т.п., и какие можете выделить?

OSINT это не то чтобы методика, это просто разведка по открытым источникам. OWASP это вообще организация, но у этой организации есть методики для тестирования веб-приложений, мобильных приложений, и мы им следуем; по крайней мере, по духу, не выполняя каждый чеклист по галочкам они могут быть довольно спорные. Методологиям OSSTMM мы следуем; по-моему, как раз в OSSTMM и изложены шаги про разведку, сканирование, эксплуатацию, постэксплуатацию, зачистку то есть, основной смысл этой методологии в том, что должны быть применены такие шаги, но дальше детализируется намного больше.

В общем, коротко да, но не буквально. Мы следуем духу этой методологии.

Q: что спрашивают на собеседованиях?

По-разному. Зависит от того, на какую позицию вы идете. Часто паттерн вопроса бывает такой. Вам описывают какую-то ситуацию например, говорят: вы получили исполнение кода на сервере Linux извне, через периметр пробились, поломали веб-сервер, вы внутри, какие выполните действия дальше? Или вы попали на рабочую станцию сотрудника, какие дальнейшие действия? Или вы нашли уязвимость в cross-site scripting на какой-то странице, там внедрена политика content security policy с такими-то параметрами, как вы будете ее обходить? Такого плана вопросы обычно бывают.

Q: какой порог входа в bug bounty, и реально ли жить только на нём?

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

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

В целом, в bug bounty много людей, которые зарабатывают большие деньги, не обладая при этом уникальными и выдающимися знаниями. Либо им повезло пару раз, либо они поняли фишку bug bounty и научились находить программы и ресурсы, в которых будут простые уязвимости. Еще часто бывает, что человек находит какую-то уязвимость на каком-то ресурсе и потом понимает, что она на самом деле очень распространена, и таким же образом можно поломать еще много компаний, монетизируя это. Реально ли жить только на bug bounty да, есть даже миллионеры, которые сотни тысяч долларов в год делают только на bug bounty. Их мало; большинство, конечно, зарабатывает довольно мало. Но достаточно велик пласт людей, которые зарабатывают хотя бы десятки тысяч в год. То есть, уже не единицы и десятки человек, а сотни.

Q: Расскажите про версии Metasploit. Я слышал, что их несколько, и среди них есть платные. В чем разница?

Я думаю, можно зайти на сайт платной версии и прочитать, в чем разница. Я давно не пользовался Metasploit pro, но там есть web-интерфейс, как минимум. Это одно из отличий; я сейчас с ходу не скажу, какие там еще отличия принципиальные. Возможно, какие-то еще модули есть.

Я думал рассказать про то, какие обычно встречаются уязвимости. На самом деле, многие компании проводят пентесты в течение года и подсчитывают количество уязвимостей разных типов, чтобы подвести статистику по итогам года. Я такую статистику не подводил, но, если говорить по ощущениям и по таким самым простым вещам, которые обнаруживаются, в инфраструктуре самые простые и действенные уязвимости, которые приносят атакующим много пользы это слабые парольные политики. Банальный перебор паролей это бич инфраструктур. Если в компании работает хотя бы 500 человек, то довольно существенная часть из них будет не особенно технически подкована. Хотя бы у одного из них обычно можно подобрать пароль брутфорсом. Особенно это прикольно работает, когда в компании внедрена парольная политика, которая заставляет, например, иметь пароль, содержащий большую букву, маленькую букву и цифру, не короче 8 символов, и менять его раз в три месяца или в месяц. Это приводит к плохим результатам. Если человека заставляют делать так, то он не может запомнить пароль. Если он не пользуется менеджером паролей со случайными паролями, то он иногда просто пишет текущий месяц с большой буквы (типа December2020). На самом деле, это очень распространено во всех типовых корпоративных инфраструктурах представьте Active Directory, сотни сотрудников с Windows на машинах. Можно просто брать текущий или прошедший месяц и год, пройтись по всем учетным записям кто-нибудь да поломается. Очень действенная атака.

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

Эта уязвимость называется insecure direct object reference небезопасная прямая ссылка на объект. В современных сервисах это самая распространенная уязвимость, по моим наблюдениям. Более классические уязвимости, которые были распространены в прошлом например, SQL-инъекции и межсайтовый скриптинг встречаются все-таки реже в сервисах, написанных с использованием современных фреймворков. Особенно SQL-инъекции. Но вот логические ошибки попадаются, потому что от них фреймворки не спасают. Разработчик должен сам думать о том, как защититься, как реализовать ролевую модель и разграничить доступ к объектам.

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

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

Найти в этих 100 мб уязвимость может быть сложно но эксплуатировать может быть легко. Или наоборот эксплуатировать сложно из-за каких-то ограничений, из-за фаерволов. Но в отчетах по пентесту нет градации простые-сложные: есть градация по критичности. Критичность складывается из уровня риска то есть, из уровня ущерба и из вероятности эксплуатации. Хотя вероятность это почти то же, что сложность. Если нам для нахождения уязвимости потребовалась куча времени и навыки senior-пентестера, то мы можем оценить вероятность эксплуатации как невысокую. Мы нашли за три недели копания, а другие могут вообще не найти. Но при этом ущерб от этой уязвимости может быть высоким. Совместив такие показатели, получаем средний уровень риска.

Отчеты по пентесту имеют довольно стандартный шаблон. Бывает вводная часть, где просто описывается, что мы пентестили и зачем, какая модель нарушителя внешний или внутренний доступ, есть учетки у него или нет. Дальше идет резюме, в котором описывается кратко результат: какие уязвимости обнаружены, какой уровень защищенности все плохо или все хорошо. Описывается каждая уязвимость, демонстрируется со скриншотами, дается код, чтобы разработчики компании все поняли. И даются рекомендации. Там же дается оценка вероятности и уровня ущерба.

Q: много ли у вас при проведении пентеста встречались непропатченные Windows 7 c ms17-010 в корпоративном секторе?

Бывают. Обычно не в домене, правда. Не слишком много.

Q: как понять, что пора на собеседование? Как выделится среди других кандидатов? (возможно знания языков программирования или аккаунт на площадках по типу HackTheBox)

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

Q: можете дать рекомендации по поводу литературы и ресурсов для закладки основ?

Да, правда, в не очень удобном формате.



Но сейчас нет недостатка в литературе сложность, скорее, в том, чтобы выбрать из массы материалов то, что подходит вам. Гуглите pentest courses сразу будет куча всего. Площадка HackTheBox отличная; я ничего не решал на ней, но имею представление. Думаю, многим навыкам там можно обучиться.

Q: какой ещё язык программирования стоит изучить, кроме Python и Bash?

Bash, наверно, действительно нужно уметь. Кстати, есть отличная площадка OverTheWireBandit, где можно хорошо потренировать Bash. А так достаточно одного языка, которым вы владеете в достаточной мере, чтобы выполнять задачи. Конечно, бывают такие задачи, для которых Python не подойдет например, если нужно быстро собирать данные с множества хостов по всему интернету. Но для большинства задач он подойдет. Однако, чем больше языков вы знаете хотя бы на уровне понимания парадигмы и чтения синтаксиса тем лучше. В ходе пентестов и аудитов вы будете сталкиваться с разными стеками и с приложениями, написанными на разных языках нужно уметь понимать, как они работают. Кроме того, даже если вы совсем не занимаетесь аудитом исходников ПО занимаетесь только инфраструктурой то вам все равно следует знать разные языки. Очень многие инструменты написаны не на Python. Если инструмент будет плохо работать возможно, придется разбираться в нем, читать код, патчить. Скажем, в инфраструктуре Windows это в основном C#.

Q: какие сертификаты наиболее востребованы для редтима, но кроме OSCP?

Именно для редтима? Есть сертификаты, которые так и называются Certified Redream Professional, Certified Redteam Expert, Pentester Academy. Но они не очень востребованы, они просто есть. Затрудняюсь ответить, какие именно действительно востребованы. Востребованность исчисляется тем, сколько работодателей вписывает их в требования вакансий, и сколько заказчиков в тендерные требования. Часто бывает, что требуется от сотрудников подрядчика наличие сертификата и там чаще всего OSCP или CEH старый сертификат, даже скорее теоретический, а не практический.

Q: нужны ли навыки декомпилирования в пентесте?

В какой-то мере да. Особенно если вы работаете именно с application security, в анализе защищенности приложений. Там это может пригодиться. Но чаще всего с мобильными приложениями: для них вам могут не давать исходники, но само приложение у вас будет, и вы будете его декомпилировать, реверс-инжинирить.

Вообще, если спрашивать на тему нужны ли навыки ну, про любой навык можно сказать, что он полезен. Но невозможно знать абсолютно все. Знать много хорошо, но нужно все-таки понимать свою специализацию, понимать, что вы умеете лучше. Даже внутри web-приложений бывают специализации; бывают специализации по индустриям например, человек может хорошо знать уязвимости платежных сервисов. Неважно, на уровне web или финансовой логики; бывают люди, которые только и занимаются тем, что тестируют платежные терминалы, интернет-банкинг, карточный эквайринг и так далее. Вроде бы это все одна область, но на самом деле там очень разные штуки. И хардвер может быть разный (смарткарты, терминалы), и web, и API, и мобильные приложения. Одним словом, любой навык может быть полезен, но не обязателен. Обязательно иметь какую-то критическую массу навыков и знаний.

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

Q: за сколько часов управились с экзаменами OSCP?

Не помню, несколько часов. Честно говоря, я сдавал два раза; в первый раз я прорешал все в течение дня, написал 80-страничный отчет, но не прочитал требования к нему. Оказалось, что нужен определенный формат скринов, и мой отчет не приняли, поэтому пришлось сдавать снова. На пересдаче ушло часов 5.

Q: посоветуйте русскоязычных блогеров в сфере пентеста

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

Q: какие шансы у Linux/Network Administrator попасть в пентест?

Прямая дорога в инфраструктурный пентест. Будет достаточно несложно вкатиться, если администратор хорошо понимает сеть и Linux. Единственное будет еще короче дорога, если это Windows-администратор; корпоративные сети это обычно Windows. Но все равно нормально, это хороший бэкграунд.

На самом деле, у меня есть Google-табличка, куда я выписал набор знаний для разных специализаций и уровней пентестеров. Стажер, младший, средний, старший, с разделением на Web и инфраструктуру. Наверно, ссылку можно будет вставить; она будет и на Хабре, если будет итоговый пост. Это мои субъективные требования, но я их немного менял по фидбеку от людей, которые давали свои замечание и предложения и добавляли что-то. Поэтому можно считать их плюс-минус адекватными и ориентироваться на них. Там и сертификации перечислены, и даже зарплатные расценки на рынке, и направления для развития.

Q: как красиво уйти от вопроса от заказчика, который он может задать в процессе пентеста Ну что, нашли что-нибудь?

А зачем уходить от вопроса? Ответьте. Если еще не нашли ничего, то не нашли. Вам же, рано ли поздно, придется отвечать на этот вопрос в отчете. Поэтому нормально, что вас спросили через неделю после начала работы и вы говорите, что не нашли.

Q: где смотреть вакансии на пентестера? В hh очень мало.

Да, в Headhunter мало. Обычно все ищут друг друга по знакомству, поэтому, наверно, надо просто общаться с людьми. Можно разместить свое резюме возможно, в таком режиме будет больше внимания. Также можно поискать вакансии в LinkedIn. И еще бывают Telegram-каналы, в которых выкладывают вакансии

Q: что вы думаете про площадку tryhackme?

Не знаю такую. Сейчас очень много площадок, по web я бы порекомендовал Portswigger Academy порешать. Portswigger это компания, которая разрабатывает Burp.

Q: пентест и удаленка. Реально? Или в связи со спецификой работы стараются набирать в офис?

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

Q: есть ли публичная БД или список типичных уязвимостей, чтобы поучиться? Или книжка какая-нибудь?

Да, например, OWASP Top 10. Это достаточно спорная штука, но это топ-10 уязвимостей в web-приложениях. Есть еще CWE (Common Weakness Enumeration) попытка классификации всех уязвимостей, разбиение их на иерархическую систему. Можно посмотреть, там есть примеры конкретных уязвимостей. Другой каталог CVE, это просто каталог уязвимостей в различном ПО. Там тоже есть реальные примеры, можно посмотреть, разобраться, как работают эксплоиты.

Q: можете прочитать немного вашу табличку со спецификациями?

Голосовой формат, конечно, странный. Я могу расшарить экран. [экран не расшаривается] Я думаю, ссылка на документ будет на хабре. Там написано, сколько нужно опыта (в годах) для каждого уровня; это, конечно, субъективно скорее, как ориентир. Описаны навыки, в произвольном порядке. Зарплата и сертификация, на которые можно ориентироваться. И путь роста что делать, чтобы выйти на следующий уровень. Например, для junior pentester нужно около года опыта или работы, или изучения; если человек не изучал хотя бы год не занимался IT или программированием и сразу попытался вкатиться в пентест, то он вряд ли имеет знания и навыки. Основные требования на этом уровне общее знакомство с методологией пентеста, знание основ технологии, умение пользоваться Linux и писать простые скрипты, которые работают с сетью (парсеры, например), знание регулярных выражений, знание протокола HTP, работа с инструментами сканерами уязвимости и Burp. В общем, почитайте, я не буду все перечислять.

Q: что делать в условиях, когда почти все вакансии требуют от 2ух лет опыта? Залипнуть в Bug Bounty и HackTheBox или пытаться пробиться на уровень, которому не соответствуешь?

Это фигня. Требуют и требуют на самом деле, смотреть-то будут на знания. Вы можете записать в опыт как раз bug bounty и HackTheBox. Если вы реально не соответствуете нужному уровню по знаниям и пониманию значит, не соответствуете. Но формальный критерий по количеству лет опыта не так важен, я думаю.