Как стать автором
Обновить
4
0
Михаил Румянцев @Zlodeykin

Пользователь

Отправить сообщение

ModelOps на практике: переходим от отверточной сборки к конвейеру по управлению моделями

Время на прочтение8 мин
Количество просмотров3.5K


Привет хабр! Меня зовут Артем Глазков, я работаю консультантом в российском подразделении компании SAS. Сегодня я хочу рассказать про операционализацию аналитики на практическом примере проекта, который я сделал совместно с моим коллегой Иваном Нардини для крупной итальянской сырьевой компании. Я постараюсь сфокусироваться на наиболее важных деталях и преимуществах подхода ModelOps.

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

После внедрения задача инструментов управления жизненным циклом моделей заключается в том, чтобы постоянно поддерживать модель в форме. Мир вокруг модели меняется — в отсутствие настроенного процесса контроля качества работы модели рано или поздно точность ее работы упадет ниже приемлемого значения. Инструменты мониторинга моделей позволяют своевременно выявить потребность в дообучении. Обновленная модель сможет увидеть новые закономерности в данных и правильно их учесть. В результате, удастся обеспечить стабильно высокое качество работы модели на этапе эксплуатации, а значит получить больше практической пользы от каждой разработки.
Читать дальше →
Всего голосов 9: ↑9 и ↓0+9
Комментарии2

Пишем чат-бот на Python + PostgreSQL и Telegram

Время на прочтение8 мин
Количество просмотров69K

Пошаговое руководство написания чат-бота на языке Python.

Установим Python и библиотеки на Debian, подключим PostgreSQL, получим вопросы и ответы, подключим морфологию и нормализуем слова, запустим чат-бота в Telegram.

Голая практика и полный листинг с комментариями.

Смотрим далее
Всего голосов 1: ↑1 и ↓0+1
Комментарии3

SQL HowTo: генерируем лабиринты (алгоритм Прима и геометрические типы)

Время на прочтение7 мин
Количество просмотров6.2K

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

Причем работа с графами - это не просто разминка для ума, а вполне себе прикладная задача. Например, в прошлой статье мы сделали "из мухи - слона" волновым алгоритмом Ли, аналогичным используемому у нас в СБИС при расчете себестоимости в многокомпонентных актах выпуска.

А сегодня мы научимся генерации случайных лабиринтов алгоритмом Прима с использованием геометрических типов данных.

Читать далее
Всего голосов 33: ↑33 и ↓0+33
Комментарии2

Профессиональное выгорание в ИТ (результаты исследования «Моего круга»)

Время на прочтение13 мин
Количество просмотров64K


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

Большинство вопросов анкеты строилось на материалах мастер-класса Наталии Дзеружинской, доктора медицинских наук, профессора, врача-психиатра высшей квалификационной категории, проведённого ею в рамках «Школы менеджеров «Стратоплан»» (видеозаписи 5 мастер-классов школы).

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

Как мы узнали, более 50% ИТ-специалистов имеют опыт профессионального выгорания, причём половина из них прошли через этот опыт 2 и более раза. Для работодателя подобное выгорание сотрудников имеет довольно серьёзные последствия: до 20% сотрудников находятся регулярно в подобном состоянии, только 25% выгорающих остаётся на прежнем месте работы. А значит, довольно большая часть сотрудников работает крайне неэффективно и мешает другим, плюс постоянно нужно вкладывать средства в рекрутинг и адаптацию новых сотрудников взамен выгоревших. Если работодатель научится управлять процессом выгорания, то сможет экономить много материальных и моральных сил для своей компании.
Читать дальше →
Всего голосов 55: ↑54 и ↓1+53
Комментарии115

Как распознать липовые проекты Agile

Время на прочтение5 мин
Количество просмотров13K
От переводчика: это инструкция DIB Guide: Detecting Agile BS (версия 0.4), которую Комитет по инновациям Министерства обороны США (DIB) опубликовал в открытом доступе 9 октября 2018 года.

Agile — модное словечко в разработке ПО, так что все софтверные проекты Минобороны теперь почти по умолчанию объявлены «гибкими». Настоящий документ поможет руководителям программ и специалистам Минобороны отличить софтверные проекты с действительно гибкой методологией от проектов, которые под маской Agile просто используют «водопад» или «спираль» (“agile-scrum-fall”).
Читать дальше →
Всего голосов 13: ↑13 и ↓0+13
Комментарии5

Почему менеджеры не изменяют?

Время на прочтение10 мин
Количество просмотров16K
Ключевой проблемой любой организации являются изменения.

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

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

Если у вас проблемы с продажами, вам нужны изменения. Очевидно? Вроде да. Или продукты продаете не те, что нужны рынку, или их слишком мало, или слишком много, или сроки срываете, или качество — недопустимо низкое, или продавцы хамят клиентам – неважно, это причины. Чтобы эти причины перестали оказывать влияние на систему продаж, нужны изменения.

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

Если у вас проблемы с автоматизацией, то вам нужны изменения. Очевидно? Вроде да. Или платформу сменить, или программный продукт другой взять, или программистов нанять, или программистов разогнать, или порядочного аутсорсера найти (ха-ха), или перестать пользоваться колхозным интегратором и нанять федерального, или послать федералов и найти в своей деревне увлеченного фаната, или пересмотреть управление ИТ-отделом, или изменить мотивацию программистов. Не важно, что именно, но что-то надо менять.
Читать дальше →
Всего голосов 30: ↑26 и ↓4+22
Комментарии49

Проактивная оптимизация производительности БД Oracle

Время на прочтение20 мин
Количество просмотров28K
Первое, с чем мы сталкиваемся, когда говорим о проактивной оптимизации — не известно, что нужно оптимизировать. «Сделай то, не знаю, что».

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

Основные цели проактивной оптимизации


Основные задачи проактивной оптимизации отличаются от задач реактивной оптимизации и состоят в следующем:

  • избавление от узких мест в БД;
  • уменьшение потребления ресурсов БД.

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



Если вы работаете с боевыми серверами, то хорошо представляете, что значат инциденты производительности. Нужно всё бросить и быстро решать проблему. ООО РНКО «Платежный центр» работает с многими агентами, и для них очень важно, чтобы таких проблем было как можно меньше. Александр Макаров на HighLoad++ Siberia рассказал, что было сделано, чтобы значительно уменьшить количество инцидентов производительности. На помощь пришла проактивная оптимизация. А почему и как ее производят на боевом сервере, читайте ниже.
Всего голосов 19: ↑19 и ↓0+19
Комментарии8

Почему я не использую story points для планирования спринта

Время на прочтение3 мин
Количество просмотров16K
Привет, Хабр! Представляю вашему вниманию перевод статьи «Why I Don’t Use Story Points for Sprint Planning» автора Mike Cohn.

Как описано в «Agile Estimating and Planning», я большой поклонник story points для оценки бэклога продукта. Тем не менее, я также рекомендую оценивать бэклог спринта в часах, а не в story points. Почему это кажущееся противоречие? Ранее я писал о причинах. Я рекомендую использовать разные единицы измерения (points и часы) для различных бэклогов.
Читать дальше →
Всего голосов 23: ↑19 и ↓4+15
Комментарии49

Сравниваем TCO покупки «железа» и аренды облака

Время на прочтение25 мин
Количество просмотров29K


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

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

Цель этой статьи — разобраться в методике TCO для разных вариантов получения права пользования ИТ-инфраструктурой и провести соответствующие расчеты, дабы выявить наиболее экономически эффективную альтернативу.
Читать дальше →
Всего голосов 15: ↑14 и ↓1+13
Комментарии56

Неотвратимость наказания, эффективность внезапных проверок

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

image

Борьба популяций цифровой плесени под воздействие испепеляющего солнца.

Предуведомление. Статья состоит из трёх частей, и первые две кажутся вообще друг к другу никак не относящимися, однако есть третья объединяющая их.
Читать дальше →
Всего голосов 63: ↑61 и ↓2+59
Комментарии91

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

Время на прочтение9 мин
Количество просмотров15K


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

В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно*

* за исключением считанных случаев в сложившихся высокопроизводительных командах

Вот уже несколько месяцев я размышлял о том, почему создание качественного софта плохо сочетается с оценочными сроками и планированием вообще. За свою карьеру я видел проекты, выстроенные по самым разным моделям (каскадная, подлинно гибкая, гибко-каскадная), и у всех них была одна общая черта: независимо от того, над каким проектом мы работаем, если он делался «по науке» (т.e., мы не позволяли себе грязных уловок, из-за которых нам бы потом снились кошмары), то мы всегда срывали сроки.

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

Переведено в Alconost
Читать дальше →
Всего голосов 31: ↑30 и ↓1+29
Комментарии30

Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет

Время на прочтение14 мин
Количество просмотров95K


Если вы работаете в IT-компании, то, скорее всего, ваши процессы построены вокруг известного продукта Atlassian — Jira. На рынке есть множество таск-трекеров для решения тех же задач, в том числе open-source-решения (Trac, Redmine, Bugzilla), но, пожалуй, именно Jira имеет сегодня самое широкое распространение.

Меня зовут Дмитрий Семенихин, я тимлид в компании Badoo. В небольшом цикле статей я расскажу, как именно мы используем Jira, как настраивали её под свои процессы, что хорошего «прикрутили» сверху и как тем самым превратили issue-трекер в единый центр коммуникаций по задаче и упростили себе жизнь. В этой статье вы увидите наш флоу изнутри, узнаете, как можно «докрутить» свою Jira, и прочтёте о дополнительных возможностях инструмента, о которых могли не знать.

Статья ориентирована прежде всего на тех, кто уже использует Jira, но, возможно, испытывает сложности с интеграцией её стандартных возможностей в существующие в компании процессы. Также статья может быть полезна компаниям, которые используют другие таск-трекеры, но столкнулись с некоторыми ограничениями и подумывают о смене решения. Статья построена не по принципу «проблема — решение», в ней я описываю сложившийся инструментарий и фичи, построенные нами вокруг Jira, а также технологии, которые мы использовали для их реализации.
Читать дальше →
Всего голосов 63: ↑62 и ↓1+61
Комментарии23

Что почитать об ITSM: книги, блоги и свежие статьи

Время на прочтение6 мин
Количество просмотров20K
Сегодня об ITSM и ITIL пишут все чаще — в том числе крупные площадки вроде Forbes и TechRadar. Охватить все многообразие источников и публикаций физически невозможно.

Потому мы подготовили для вас дайджест, в котором собрали наиболее интересные ресурсы, посвященные внедрению ITSM в компаниях разных «калибров». Это — книги и статьи про управление услугами, а также личные блоги ITSM-экспертов.

Читать дальше →
Всего голосов 22: ↑19 и ↓3+16
Комментарии2

Как команда технарей свою компанию создавала, сезон 2 (жизнь в кризис)

Время на прочтение9 мин
Количество просмотров20K

Первая наша статья получила большой отклик на Хабре, 62 тысячи просмотров, +94 голосов, 340 раз добавили в избранное. Это очень круто, и мы с радостью расскажем, что у нас произошло за последний год.

В этом сезоне вы узнаете:
  • как в первый же год заработать 7 млн. в обороте на аутсорсе;
  • как потерять свой первый лям и не сойти с ума;
  • как стать спасителями для ваших клиентов, снять с них боль и ад вечно проблемного IT;
  • как выживать в кризис;
  • и супербонус для тех, кто хочет начать свой бизнес: наша бизнес-модель с преферансом и балеринами. Математически обоснованный расчет стоимости нормочаса на аутсорсе.

Читать дальше →
Всего голосов 24: ↑24 и ↓0+24
Комментарии28

Как команда технарей свою студию создавала. Опыт первых месяцев. Достижения, фейлы, умозаключения…

Время на прочтение9 мин
Количество просмотров137K

Уверен, многих технарей посещала идея создания своего бизнеса. Вот и у нас в определенный момент все звёзды сложились так, что казалось — это беспроигрышный вариант: сильная техническая команда, откуда ни возьмись появились менеджеры, готовые продавать наши услуги, есть даже пара проектов на старт. Грех не попробовать. И мы рискнули. Фактически всё надо ставить с нуля.
Читать дальше →
Всего голосов 126: ↑110 и ↓16+94
Комментарии118

Как команда технарей свою компанию создавала, сезон 3 (наконец-то полетело!)

Время на прочтение7 мин
Количество просмотров8.6K


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

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

Читать дальше →
Всего голосов 26: ↑25 и ↓1+24
Комментарии23

Как измерить успех. Стратегии мониторинга и их связь с бизнес-проблемами

Время на прочтение18 мин
Количество просмотров11K

Перед тем, как ответить на вопрос «Как измерить успех?», надо понять, что значит «успех» именно для вас. Для Dev и Ops определение успеха отличается. Для Dev успешный проект полностью проходит тестирование. Для эксплуатации — мониторинг. Тестирование и мониторинг нужны, но тесты никогда не дают 100% покрытия проблемы, а ответа 200 от HTTP недостаточно, чтобы быть уверенным в том, что система хорошо работает. Leon Fayer на РИТ++ отстаивал точку зрения, что DevOps платят не за то, чтобы все метрики в мониторинге были в зеленой зоне. Платят за то, чтобы пользователи были довольны. Если недовольны — бизнес теряет деньги, и никого не волнует, что все зеленое.


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




О спикере: Leon Fayer родился в когда-то дружественной республике, но вырос в США. Начал заниматься программированием очень много лет назад, и за это время работал программистом, менеджером — кем только не работал. Участвовал в стартапах — некоторые были более удачные, а некоторые не очень.


Много лет Леон работает в OmniTI. Эта компания специализируется на разработке масштабируемых систем, поэтому Леон имеет уникальную возможность проектировать и строить системы для самых посещаемых сайтов в мире — Wikipedia, National Geographic, White House, MTV и т.д.

Всего голосов 42: ↑39 и ↓3+36
Комментарии8

Результаты Обсуждения на тему: Личное, Командное и Организационное мышление” (ЛАФ 2018)

Время на прочтение2 мин
Количество просмотров1.3K
В своих поисках ответа, как принимать лучшие стратегические решения (а заодно доказать, что думать полезно) я набрел на две ключевые идеи, которые мне не дают покоя, потому что переворачивают все классические представления о том как происходит принятие решений:

  • Субъектом мышления является не индивид, а группа. ( Курс командного коучинга Девида Клаттербака 2-й уровень)
  • 3 уровня мышления из Integrated Thinking Framework (Richard King):
    Личный, командный, организационный.

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

В рамках первичного обсуждения, сформировалось понимание что в контексте группового мышления лучше всего подходит перспектива, в которой мышление это процесс определяющий эффективность принятия Решений. Немного доработанная схема приведена на рисунке.
Читать дальше →
Всего голосов 10: ↑10 и ↓0+10
Комментарии14

5 моделей эффективного командного взаимодействия

Время на прочтение6 мин
Количество просмотров76K
Выбор моделей и подходов для повышения эффективности работы команды — это извечная головная боль менеджеров продуктов, тим лидов, собственников бизнеса, HR, ученых и психологов.

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

image
Читать дальше →
Всего голосов 11: ↑10 и ↓1+9
Комментарии2

NewSQL = NoSQL+ACID

Время на прочтение15 мин
Количество просмотров33K

До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.

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

Как это работает и что получилось — читай под катом.
Читать дальше →
Всего голосов 61: ↑60 и ↓1+59
Комментарии60

Информация

В рейтинге
Не участвует
Откуда
Балашиха, Москва и Московская обл., Россия
Зарегистрирован
Активность