«Никто ничего не знает»  - знаменитая цитата Уильяма Голдмана, сказанная в 80х. Имелась ввиду неспособность Голивудских продюсеров предугадывать успех или провал фильма в прокате. Сам Голдман - дважды обладатель Оскара и один из самых великих сценаристов в истории кинематографа. Короче, ему можно верить. 

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

Особенно, успех ролика на Ютуб. 

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

На самом деле почти никто не знает, что такое GitOps. Я тоже заблуждался, пока не начал готовить доклад, а потом статью по этой теме. Самое распространенное определение GitOps — это «хранение состояния в Git», но оно не единственное и не самое главное. Это звучное словечко  придумали в Weaveworks, но его название несколько разнится с его реальным пониманием. Созвучие с DevOps — скорее, маркетинговый ход, чем реальное отражение сущности. Основная идея GitOps в том, что помимо хранения состояния в Git, у нас есть непрерывный процесс его синхронизации с реальным миром, то есть, что у вас Kubernetes-кластере или где либо ещё в вашем окружении.

Меня зовут Андрей Квапил. Я работал в чешском хостинге WEDOS. Он не сильно популярен в России, но это крупнейший хостинг на территории Чехии (просто Чехия маленькая).  Сейчас я работаю во Фланте, но именно на примере европейского хостинга WEDOS, хочу рассказать историю имплементации GitOps.

Часть 2/3 тут
Часть 3/3 тут

Всем привет! В этой статье я хочу упорядочить информацию и поделиться опытом создания и использования внутреннего кластера Kubernetes.

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

0. Вступление

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

Что такое MPEG-DASH

DASH — Dynamic Adaptive Streaming over HTTP. Стандарт DASH ISO/IEC 23009-1:2012 был разработан группой MPEG в 2011 году

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

Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.

Платить работникам рыночную зп, или выше рынка? Раздувать штат "сдельщиков", или выжимать максимум производительности из каждого сотрудника? Что делать, если сотрудники работают "с прохладцей"? Ищем ответы у классика менеджмента Ф.У.Тейлора.

Эта заметка — попытка вкусно рассказать о книге Тейлора 1911 года, вызвать у вас желание её прочесть, и не наспойлерить. Из заметки вы узнаете, что сказал Ленин по поводу этой книги, а также мнение Питера Друкера: кто круче — Маркс, или Тейлор.

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

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

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

Как же предпринимателям без технических знаний понять программистов и подружиться с разработкой? Я уверен, что залог успеха — партнерские отношения между бизнесом и инженерами. У инженеров есть видение, мнение и экспертиза. А у бизнеса есть свои цели. В то же время, инженерия — это всегда расходная статья бюджета, а не доходная. Либо компания, потратив деньги на разработку, получит профит, либо разработка, с точки зрения бизнеса, просто сжигает бюджет. Технический склад ума разработчиков зачастую концентрируется на красивом коде, использовании best practice,  настройке, рефакторинге. На это команде разработки требуется дополнительное время. А бизнес знает, что если в определенный момент времени потребность клиента не удовлетворена, позже она просто теряет смысл. Давайте разберемся, почему возникают проблемы в общении и как можно их устранить. 

Откуда берутся страхи и фобии? Как они формируются?

У человека, как и у компьютера, есть BIOS, в котором может произойти сбой и в результате возникает вирусная программа - ПСИХОТРАВМА, когда же компьютер глючит – у человека проявляются СИМПТОМЫ.

Объясняю:

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

Событие забылось. Прошло лет 5-10, родители поссорились и разошлись. Для ребенка это был сильный стресс. В этот момент сформировалась ПСИХОТРАВМА.

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

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

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

Важно понимать, что нервная система накапливает реакции на стресс в виде телесных зажимов.

Поэтому в трудную минуту ощущаем «как сдавливает горло от несправедливости», «колит в груди от обиды», «подкашиваются ноги от страха»…

Запомните, чтобы починить систему, нужен работающий компьютер, а не выключенный. Гипноз - не сон.

В режиме бодрствования до BIOS (до подсознания) тоже не добраться. Нужно сначала перейти в режим редактирования опыта.

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

Недавно мы опросили рекрутеров агентства GetIT о том, какие зарплаты хотят разработчики. Они выкатили нам большой список ожиданий, в зависимости от языков и направлений. Например, верхняя цифра в вилке ожидаемых зарплат для C#-разработчиков — 280 000. И она не самая большая: сеньоры в Android и Java-разработчке рассматривали ожидаемые зарплаты по 400 000. 

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

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

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

Реализуем севооборот

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

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

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

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