Чеклисты
Чеклисты — это очень крутая тема, незаменимый помощник в процессах, при исполнении которых нельзя что-то проебать. Человеческий фактор всегда будет вашим противником. И неважно, кто будет выступать источником этого фактора: ваши коллеги, подрядчики, сотрудники или вы сами. Законы Мерфи работали и всегда будут работать: если что-то может пойти не так, оно обязательно пойдет не так.
Например вот авиация. Суперответственная тема и на последней точке за жизнь сотен пассажиров всегда отвечает пилот. В самолете все системы задублированы по много раз, это крайне надежное творение инженерной мысли и если бы не человек, который им управляет, то доверия к нему было бы гораздо больше. Но пилот необходим для принятия важных решений в полете и чтобы снизить риск его возможного негативного влияния на самолет, у пилотов всегда есть чеклист, по которому он должен пройти перед тем, как начнет выполнять любые операции с воздушным судном.
Это очень хорошая и полезная практика. Если вам необходимо выполнить какой-то очень ответственный процесс, потратьте два часа и составьте чеклист, вставляйте туда самые очевидные пункты, в момент "Х" вы можете про них просто забыть.
Если у вас есть какие-то рутинные операции, которые, в силу их природы нельзя автоматизировать, составьте чеклист и спасете себя от замыливания взгляда. Да еще и мозг освободите для более полезной работы.
Чеклисты — это инструмент автоматизации в тех сферах, где нельзя воспользоваться программными средствами.
Чеклисты — это очень крутая тема, незаменимый помощник в процессах, при исполнении которых нельзя что-то проебать. Человеческий фактор всегда будет вашим противником. И неважно, кто будет выступать источником этого фактора: ваши коллеги, подрядчики, сотрудники или вы сами. Законы Мерфи работали и всегда будут работать: если что-то может пойти не так, оно обязательно пойдет не так.
Например вот авиация. Суперответственная тема и на последней точке за жизнь сотен пассажиров всегда отвечает пилот. В самолете все системы задублированы по много раз, это крайне надежное творение инженерной мысли и если бы не человек, который им управляет, то доверия к нему было бы гораздо больше. Но пилот необходим для принятия важных решений в полете и чтобы снизить риск его возможного негативного влияния на самолет, у пилотов всегда есть чеклист, по которому он должен пройти перед тем, как начнет выполнять любые операции с воздушным судном.
Это очень хорошая и полезная практика. Если вам необходимо выполнить какой-то очень ответственный процесс, потратьте два часа и составьте чеклист, вставляйте туда самые очевидные пункты, в момент "Х" вы можете про них просто забыть.
Если у вас есть какие-то рутинные операции, которые, в силу их природы нельзя автоматизировать, составьте чеклист и спасете себя от замыливания взгляда. Да еще и мозг освободите для более полезной работы.
Чеклисты — это инструмент автоматизации в тех сферах, где нельзя воспользоваться программными средствами.
Воскресные развлечения. Обновляю систему с аптаймом в три с лишним года🤦♂️
Сервачок мой личный, как-то я подзабыл про него.
Заодно и проверим, насколько убунта переживет апдейт через два LTS-релиза. Буду обновлять до актуальной 20.04 LTS
UPD: пережила нормально :) Все сервисы запустились и работают. Были сложности с промежуточным обновлением до 18.04, а до 20.04 обновилась даже без ребута. Лайк👍
UPD2: Ну респект, кстати, диджитал-оушену. Больше 3 лет VM-ка у них проработала и ни единого разрыва, то бишь ребута. Мое уважение.
Сервачок мой личный, как-то я подзабыл про него.
Заодно и проверим, насколько убунта переживет апдейт через два LTS-релиза. Буду обновлять до актуальной 20.04 LTS
UPD: пережила нормально :) Все сервисы запустились и работают. Были сложности с промежуточным обновлением до 18.04, а до 20.04 обновилась даже без ребута. Лайк👍
UPD2: Ну респект, кстати, диджитал-оушену. Больше 3 лет VM-ка у них проработала и ни единого разрыва, то бишь ребута. Мое уважение.
Разработка vs Эксплуатация
Начинал я вообще фронтендером :) Тогда это называлось HTML-верстальщик и писали мы на ванильном js, тогда даж жиквери еще не вышел на большую сцену и не перевернул мир. На дворе был 2003 год. Потом было много программирования, я писал на PHP, на перле, на сях, на джаваскрипте, на tcl даже и параллельно с этим изучал линуксы.
И в какой-то момент времени понял, что просто писать код мне неинтересно. Тогда (это где-то 2008 год) еще не было такого единения разработки и эксплуатации, devops только зарождался на западе и программисты просто коммитили свой код и тут же писали новый. Судьба уже написанного их волновала только тогда, когда код к ним возвращался с уже описанными багами. Я тогда много тусил с "большими ребятами", это badoo, яндекс и все вот эти чуваки, которые меняли правила игры в индустрии. И у них было много решений на уровне эксплуатации, которые меня прям поразили. Они придумывали что-то новое там, где, казалось, уже нельзя было ничего придумать. А потом кто-то привез концепции DevOps и все, мир для меня поменялся в сторону любви к инфраструктурным решениям.
Тот факт, что я довольно долго проработал программистом, помогал мне хорошо понимать как код, так и проблемы/потребности разработчиков, а довольно хорошее знание линукса и умение его приготовить позволяло мне строить эффективные системы.
В итоге я сформулировал для себя такой ответ. Мне субъективно интереснее эксплуатация потому что:
Там тоже очень много программирования, но заказчики в подавляющем большинстве случаев внутренние и поэтому процесс идет легче.
Возможность видеть как живет код и как из него строится работающая система приносят мне куда больше интереса и удовлетворения, нежели просто написание кода. Решение задач "здесь и сейчас" — это круто и интересно.
Применение продуктового подхода в управлении инфраструктурой поворачивает многое с ног на голову и я становлюсь еще немножечко продактом. Касдев, продуктовые метрики, тайм-ту-маркет, тесный контакт с бизнесом, роадмэпы развития в отношении инфраструктуры — это неожиданный угол зрения, который позволяет совсем по-другому смотреть на все происходящее
Ну и программирование никуда не девается, возможностей для автоматизации и кастомных решений не просто много, а очень много. И можно брать и склеивать готовое, а можно писать свое — все зависит от ресурсов и моей собственной уверенности в том, что я смогу это нормально заменеджить. К тому же можно выбирать язык под свои задачи. Сейчас я предпочитаю python и golang.
Возможность влиять на процессы across the company тоже очень драйвит. В матричной структуре компании инфра/девопс — это всегда сервисная горизонталь, которая взаимодействует со всеми продуктовыми командами и строить процесс деливери на этом уровне очень интересно.
Ну и челлендж, куда же без него :) Эксплуатация — это всегда сущность, которая только тратит деньги. Напрямую команда devops/sre не влияет на прибыль и поэтому я могу вносить свою лепту в revenue только двумя путями: уменьшать расходы и оптимизировать существующие процессы. Ну и следить за выполнением SLA конечно
Последние несколько лет я сместил фокус в сторону менеджмента, не только технического, но и people management, что не менее интересно. Причем я предпочитаю позицию "играющего тренера", не уходя далеко от ручного опыта. В менеджмент я полез исключительно затем, чтобы иметь возможность быть поближе к бизнесу и принимать решения на более высоком уровне, что всегда положительно сказывается на процессах и самочувствии моей собственной команды.
"А я еще я немножечко шью" 😁
Начинал я вообще фронтендером :) Тогда это называлось HTML-верстальщик и писали мы на ванильном js, тогда даж жиквери еще не вышел на большую сцену и не перевернул мир. На дворе был 2003 год. Потом было много программирования, я писал на PHP, на перле, на сях, на джаваскрипте, на tcl даже и параллельно с этим изучал линуксы.
И в какой-то момент времени понял, что просто писать код мне неинтересно. Тогда (это где-то 2008 год) еще не было такого единения разработки и эксплуатации, devops только зарождался на западе и программисты просто коммитили свой код и тут же писали новый. Судьба уже написанного их волновала только тогда, когда код к ним возвращался с уже описанными багами. Я тогда много тусил с "большими ребятами", это badoo, яндекс и все вот эти чуваки, которые меняли правила игры в индустрии. И у них было много решений на уровне эксплуатации, которые меня прям поразили. Они придумывали что-то новое там, где, казалось, уже нельзя было ничего придумать. А потом кто-то привез концепции DevOps и все, мир для меня поменялся в сторону любви к инфраструктурным решениям.
Тот факт, что я довольно долго проработал программистом, помогал мне хорошо понимать как код, так и проблемы/потребности разработчиков, а довольно хорошее знание линукса и умение его приготовить позволяло мне строить эффективные системы.
В итоге я сформулировал для себя такой ответ. Мне субъективно интереснее эксплуатация потому что:
Там тоже очень много программирования, но заказчики в подавляющем большинстве случаев внутренние и поэтому процесс идет легче.
Возможность видеть как живет код и как из него строится работающая система приносят мне куда больше интереса и удовлетворения, нежели просто написание кода. Решение задач "здесь и сейчас" — это круто и интересно.
Применение продуктового подхода в управлении инфраструктурой поворачивает многое с ног на голову и я становлюсь еще немножечко продактом. Касдев, продуктовые метрики, тайм-ту-маркет, тесный контакт с бизнесом, роадмэпы развития в отношении инфраструктуры — это неожиданный угол зрения, который позволяет совсем по-другому смотреть на все происходящее
Ну и программирование никуда не девается, возможностей для автоматизации и кастомных решений не просто много, а очень много. И можно брать и склеивать готовое, а можно писать свое — все зависит от ресурсов и моей собственной уверенности в том, что я смогу это нормально заменеджить. К тому же можно выбирать язык под свои задачи. Сейчас я предпочитаю python и golang.
Возможность влиять на процессы across the company тоже очень драйвит. В матричной структуре компании инфра/девопс — это всегда сервисная горизонталь, которая взаимодействует со всеми продуктовыми командами и строить процесс деливери на этом уровне очень интересно.
Ну и челлендж, куда же без него :) Эксплуатация — это всегда сущность, которая только тратит деньги. Напрямую команда devops/sre не влияет на прибыль и поэтому я могу вносить свою лепту в revenue только двумя путями: уменьшать расходы и оптимизировать существующие процессы. Ну и следить за выполнением SLA конечно
Последние несколько лет я сместил фокус в сторону менеджмента, не только технического, но и people management, что не менее интересно. Причем я предпочитаю позицию "играющего тренера", не уходя далеко от ручного опыта. В менеджмент я полез исключительно затем, чтобы иметь возможность быть поближе к бизнесу и принимать решения на более высоком уровне, что всегда положительно сказывается на процессах и самочувствии моей собственной команды.
"А я еще я немножечко шью" 😁
👍1
Ngrok
Продолжаем #полезняшки теперь уже не платформами, а инструментом. Сегодня у меня на карандаше отличная тулза https://ngrok.com/
Инструмент не нов и достаточно известен и я с удовольствием расскажу про него. Ngrok позволяет зашарить любое приложение с открытым портом в интернет буквально в одно действие. Запускаете приложеньку у себя на локалхосте, например веб-сервер на порту 8080. Запускаете ngrok и говорите ему, что у вас на порту 8080 висит приложенька. Он в ответ выдает вам адрес вида
Из коробки есть SSL. У софтины есть свой собственный веб-интерфейс, живущий на 127.0.0.1:4040
Можно поднять несколько видов туннелей: http, tcp и tls. Соответственно, можно и ssh затуннелировать вполне, например
На бесплатном тарифе вам доступны 1 процесс online, 4 туннеля и 40 коннектов в минуту. Можно, кстати, даже без регистрации, но тогда туннель умрет через 2 часа
Для любителей поковыряться ручками и параноиков есть опенсорсная альтернатива, написанная на node.js: https://localtunnel.github.io/www/ Можно захостить у себя и также пробрасывать туннели одним движением. И не платить ничего за полный функционал🙂
Продолжаем #полезняшки теперь уже не платформами, а инструментом. Сегодня у меня на карандаше отличная тулза https://ngrok.com/
Инструмент не нов и достаточно известен и я с удовольствием расскажу про него. Ngrok позволяет зашарить любое приложение с открытым портом в интернет буквально в одно действие. Запускаете приложеньку у себя на локалхосте, например веб-сервер на порту 8080. Запускаете ngrok и говорите ему, что у вас на порту 8080 висит приложенька. Он в ответ выдает вам адрес вида
http://d52ccfa03be8.ngrok.io/ и вуаля! Ваше приложение доступно через интернет. Незаменимая штука, когда надо по-быстрому зашарить кому-нибудь приложение с локалхоста. Ну или вебхук повесить какой-нибудь. Из коробки есть SSL. У софтины есть свой собственный веб-интерфейс, живущий на 127.0.0.1:4040
Можно поднять несколько видов туннелей: http, tcp и tls. Соответственно, можно и ssh затуннелировать вполне, например
На бесплатном тарифе вам доступны 1 процесс online, 4 туннеля и 40 коннектов в минуту. Можно, кстати, даже без регистрации, но тогда туннель умрет через 2 часа
Для любителей поковыряться ручками и параноиков есть опенсорсная альтернатива, написанная на node.js: https://localtunnel.github.io/www/ Можно захостить у себя и также пробрасывать туннели одним движением. И не платить ничего за полный функционал🙂
Ngrok
ngrok | API Gateway, Kubernetes Ingress, Webhook Gateway
ngrok simplifies app delivery by unifying API gateway, Kubernetes ingress, multi-cluster load balancing and more with ngrok's Universal Gateway.
Увеличение на порядок
Увеличение на порядок является качественным шагом, а не количественным. Не всегда получив увеличение трафика в 10 раз вы можете решить проблему добавив кратное количество машин. Вы получаете новую задачу, которую нужно решать с помощью других алгоритмов
Хайлоад начинается там, где перестают работать стандартные решения. Хайлоад это про решение инженерных задач, а не про умение гуглить или запустить плейбук ансибл
Поэтому на собеседованиях я стараюсь проверить как человек думает, а не насколько хорошая у него память
Увеличение на порядок является качественным шагом, а не количественным. Не всегда получив увеличение трафика в 10 раз вы можете решить проблему добавив кратное количество машин. Вы получаете новую задачу, которую нужно решать с помощью других алгоритмов
Хайлоад начинается там, где перестают работать стандартные решения. Хайлоад это про решение инженерных задач, а не про умение гуглить или запустить плейбук ансибл
Поэтому на собеседованиях я стараюсь проверить как человек думает, а не насколько хорошая у него память
Писательский блок
Состояние, знакомое любому творческому человеку. А айтишники, в большинстве своем, люди творческие вне зависимости от того, какой специализации посвятили они свою карьеру. И вот это знакомое тяжелое состояние, когда хочется что-то сделать, но не знаешь, что. Хочется начать новый пет-проект, но сидишь и бессмысленно смотришь в окно редактора с пустым файлом. Хочется написать статью, но курсор одиноко мигает на белом фоне уже другого редактора. Писательский блок. Кажется, что все уже написано и чего-то нового миру ты уже дать не можешь
Я сейчас готовлюсь к выступлению на конференции и тоже словил это состояние. Мне кажется, что моя тема заезженна и избита, доклад будет капитанским и я бессмысленно смотрю на блокнот, в котором я пытаюсь сделать план доклада. Вместо плана страница покрывается диковинными закорючками и мои мысли тоже очень похожи на этот хаос.
А потом мне пришла в голову одна очень простая вещь. Я подумал: "а зачем и для кого я вообще это делаю?" Зачем это лично мне и что я хочу выразить?
Выступить меня попросили друзья, это просто уважение к их просьбе? Нет, точно нет.
Это какое-то стремление к самореализации? Уже ближе, но все-таки тоже нет
Я хочу аккумулировать свой опыт и передать его в сжатом и понятном виде? Так, это уже очень близко
Я понимаю путь, по которому я прошел и хочу помочь пройти его тем, кто тоже решит это сделать. Вот оно, это отозвалось во мне максимально.
И писать стало легко, тезисы доклада и план будущего выступления прорисовались достаточно быстро.
В любом деле очень важно честно ответить себе, зачем ты это делаешь. И найдя ответ, делать свою текущую активность максимально хорошо, потому что причина важна для тебя. Или не делать вообще, потому что в поисках ответа ты осознаешь неважность причины
"Создать шедевр легко. Просто стань совершенным и твори естественно"
Состояние, знакомое любому творческому человеку. А айтишники, в большинстве своем, люди творческие вне зависимости от того, какой специализации посвятили они свою карьеру. И вот это знакомое тяжелое состояние, когда хочется что-то сделать, но не знаешь, что. Хочется начать новый пет-проект, но сидишь и бессмысленно смотришь в окно редактора с пустым файлом. Хочется написать статью, но курсор одиноко мигает на белом фоне уже другого редактора. Писательский блок. Кажется, что все уже написано и чего-то нового миру ты уже дать не можешь
Я сейчас готовлюсь к выступлению на конференции и тоже словил это состояние. Мне кажется, что моя тема заезженна и избита, доклад будет капитанским и я бессмысленно смотрю на блокнот, в котором я пытаюсь сделать план доклада. Вместо плана страница покрывается диковинными закорючками и мои мысли тоже очень похожи на этот хаос.
А потом мне пришла в голову одна очень простая вещь. Я подумал: "а зачем и для кого я вообще это делаю?" Зачем это лично мне и что я хочу выразить?
Выступить меня попросили друзья, это просто уважение к их просьбе? Нет, точно нет.
Это какое-то стремление к самореализации? Уже ближе, но все-таки тоже нет
Я хочу аккумулировать свой опыт и передать его в сжатом и понятном виде? Так, это уже очень близко
Я понимаю путь, по которому я прошел и хочу помочь пройти его тем, кто тоже решит это сделать. Вот оно, это отозвалось во мне максимально.
И писать стало легко, тезисы доклада и план будущего выступления прорисовались достаточно быстро.
В любом деле очень важно честно ответить себе, зачем ты это делаешь. И найдя ответ, делать свою текущую активность максимально хорошо, потому что причина важна для тебя. Или не делать вообще, потому что в поисках ответа ты осознаешь неважность причины
"Создать шедевр легко. Просто стань совершенным и твори естественно"
VS Code в браузере
В сегодняшние #полезняшки попала совершенно чумовая, на мой взгляд, штука :)
Что получится, если скрестить 1С и гитхаб? Шутка, не тот 1С, о котором вы подумали. А просто добавляем к домену гитхаба 1s и получаем VS Code прямо в вашем в браузере, а в нем открыт тот репозиторий, который вы указали в URL
Пробуем https://github1s.com/kubernetes/kubernetes
Офигенно удобно чтобы полазить по коду в нормальном редакторе. К сожалению, поставить экстеншены не получится, но и без них это очень удобно.
Идея просто отличная, я считаю
В сегодняшние #полезняшки попала совершенно чумовая, на мой взгляд, штука :)
Что получится, если скрестить 1С и гитхаб? Шутка, не тот 1С, о котором вы подумали. А просто добавляем к домену гитхаба 1s и получаем VS Code прямо в вашем в браузере, а в нем открыт тот репозиторий, который вы указали в URL
Пробуем https://github1s.com/kubernetes/kubernetes
Офигенно удобно чтобы полазить по коду в нормальном редакторе. К сожалению, поставить экстеншены не получится, но и без них это очень удобно.
Идея просто отличная, я считаю
Внутренний критик
В продолжение поста про писательский блок.
На самом деле начать зачастую мешает банальный перфекционизм (а он, как известно, всего лишь одна из форм прокрастинации). и вытекает он из того, что в голове уже сложилась не просто готовая картинка, а уже и все лавры от этой картинки пожаты. То есть кайфа от процесса не случается. А зря. Процесс приносит не меньшее удовольствие, его надо просто научиться извлекать.
Конкретно в моем случае мне надо просто разогнаться. После того, как я определился, что процесс мне нужен и важен, то я перестаю думать о том, как я начинаю, главное — начать. Пишу полную ерунду, что-то рисую, пишу странный код, который имеет мало отношения к решаемой задаче, все это нужно для того, чтобы запустить процесс. Дальше пойдет уже легче, это — вход в поток.
Обязательно необходимо декомпозировать задачу до мельчайших шагов, вычеркивать пункты из тудушника приносит определенное удовольствие и сразу видно, что нужно сделать.
Перфекционизм побеждается очень легко, на самом деле. Никто не определяет, что такое "хорошо", кроме тебя самого. Есть объективные критерии по которым будет оцениваться результат, но процесс-то итеративный. Поэтому надо как можно быстрее сделать "хорошо" в том виде, какой он есть на текущий момент и как можно быстрее получить обратную связь, чтобы приступить к следующей итерации.
Лучше сделать просто хорошо сейчас, чем охуенно и никогда. А удовольствие от сделанной работы — отличный мотиватор, на самом деле
В продолжение поста про писательский блок.
На самом деле начать зачастую мешает банальный перфекционизм (а он, как известно, всего лишь одна из форм прокрастинации). и вытекает он из того, что в голове уже сложилась не просто готовая картинка, а уже и все лавры от этой картинки пожаты. То есть кайфа от процесса не случается. А зря. Процесс приносит не меньшее удовольствие, его надо просто научиться извлекать.
Конкретно в моем случае мне надо просто разогнаться. После того, как я определился, что процесс мне нужен и важен, то я перестаю думать о том, как я начинаю, главное — начать. Пишу полную ерунду, что-то рисую, пишу странный код, который имеет мало отношения к решаемой задаче, все это нужно для того, чтобы запустить процесс. Дальше пойдет уже легче, это — вход в поток.
Обязательно необходимо декомпозировать задачу до мельчайших шагов, вычеркивать пункты из тудушника приносит определенное удовольствие и сразу видно, что нужно сделать.
Перфекционизм побеждается очень легко, на самом деле. Никто не определяет, что такое "хорошо", кроме тебя самого. Есть объективные критерии по которым будет оцениваться результат, но процесс-то итеративный. Поэтому надо как можно быстрее сделать "хорошо" в том виде, какой он есть на текущий момент и как можно быстрее получить обратную связь, чтобы приступить к следующей итерации.
Лучше сделать просто хорошо сейчас, чем охуенно и никогда. А удовольствие от сделанной работы — отличный мотиватор, на самом деле
Telegram
Happy Devops
Писательский блок
Состояние, знакомое любому творческому человеку. А айтишники, в большинстве своем, люди творческие вне зависимости от того, какой специализации посвятили они свою карьеру. И вот это знакомое тяжелое состояние, когда хочется что-то сделать…
Состояние, знакомое любому творческому человеку. А айтишники, в большинстве своем, люди творческие вне зависимости от того, какой специализации посвятили они свою карьеру. И вот это знакомое тяжелое состояние, когда хочется что-то сделать…
Продуктовые решения и инженерная культура
Поиск баланса между этими двумя понятиями — всегда очень сложное дело. Общих решений нет, все всегда упирается в частности.
Зачастую создается сильное продуктовое решение, но слабое инженерное. Продакты управляют разработкой, не желая погружаться в детали.
На каких-то общих встречах при определении стратегии все выглядит хорошо. Все помнят про техдолг и про костыли, обещают дать время. Но когда дело доходит до реализации, то часто диалог выглядит так:
— Как сделать быстрее чем вы сказали? Никак? Нет, ну как-то же можно?
— Да, можно сделать через жопу, но мы не хотим, потому что итак там уже все через жопу, это трудно поддерживать и если делать так постоянно, то скоро все умрет.
— Ну давайте в этот раз все же сделаем через жопу, а?
— Нет, мы не хотим так больше.
— Ну ок, мы согласны записать в бэклог улучшения которые вы предлагаете, но прямо вот сейчас давайте не будем их делать, а засунем их в следующий спринт, потому что нам сейчас нужна эта фича позарез?
— Ну ок
И всегда все записывается в бэклог и там тихо умирает, потому что всегда появляются новые фичи, которые позарез надо сделать.
Техдолг — он, на самом деле, выглядит также, как и обычный долг. Если не следить за выплатой кредита, то он в конце концов тебя похоронит. Также и распухший бэклог рано или поздно похоронит архитектурное решение и будет принято волевое решение провести процедуру банкротства, то есть начать все заново.
И помните. Кредит — это как обосраться на морозе. Поначалу даже тепло. А техдолг — это тот же самый кредит по сути своей.
Выплачивайте техдолг равными долями. Выделяйте время в спринте на работу только над техдолгом. Добивайтесь того, чтобы задачи из техдолга попадали в спринт.
Поиск баланса между этими двумя понятиями — всегда очень сложное дело. Общих решений нет, все всегда упирается в частности.
Зачастую создается сильное продуктовое решение, но слабое инженерное. Продакты управляют разработкой, не желая погружаться в детали.
На каких-то общих встречах при определении стратегии все выглядит хорошо. Все помнят про техдолг и про костыли, обещают дать время. Но когда дело доходит до реализации, то часто диалог выглядит так:
— Как сделать быстрее чем вы сказали? Никак? Нет, ну как-то же можно?
— Да, можно сделать через жопу, но мы не хотим, потому что итак там уже все через жопу, это трудно поддерживать и если делать так постоянно, то скоро все умрет.
— Ну давайте в этот раз все же сделаем через жопу, а?
— Нет, мы не хотим так больше.
— Ну ок, мы согласны записать в бэклог улучшения которые вы предлагаете, но прямо вот сейчас давайте не будем их делать, а засунем их в следующий спринт, потому что нам сейчас нужна эта фича позарез?
— Ну ок
И всегда все записывается в бэклог и там тихо умирает, потому что всегда появляются новые фичи, которые позарез надо сделать.
Техдолг — он, на самом деле, выглядит также, как и обычный долг. Если не следить за выплатой кредита, то он в конце концов тебя похоронит. Также и распухший бэклог рано или поздно похоронит архитектурное решение и будет принято волевое решение провести процедуру банкротства, то есть начать все заново.
И помните. Кредит — это как обосраться на морозе. Поначалу даже тепло. А техдолг — это тот же самый кредит по сути своей.
Выплачивайте техдолг равными долями. Выделяйте время в спринте на работу только над техдолгом. Добивайтесь того, чтобы задачи из техдолга попадали в спринт.
👍1
Приносите проблемы, а не задачи
Возвращаясь к вопросу про найм людей умнее себя. Одна из проблема менеджера заключается в том, что он рассматривает исполнителей как продолжение своих рук. Никого нельзя засунуть себе в голову, а менеджер долго думал над задачей, он декомпозировал ее в голове до мельчайших подробностей и поэтому ему кажется, что он должен максимально передать это знание исполнителю. И начинается подробный рассказ, как именно надо сделать то или иное, при этом из вида часто упускается именно исходная проблема
Лучше всего расслабиться и принести именно проблему в ее исходном виде. И потратить усилия на то, чтобы объяснить, зачем именно мы это делаем и куда мы идем, а реализацию оставить на откуп тому, кто непосредственно будет это делать. На самом деле этим мы убиваем сразу двух зайцев: не тратим ресурсы на перекладывание информации из одной головы в другую, тем самым избегая ее искажения и повышаем мотивацию человека, который будет делать задачу. Люди чувствуют когда им доверяют и позволяют реализоваться как профессионалам и ценят это. От менеджера же требуется лишь доверять своим сотрудникам. Микроменеджеров никто не любит и эффективность ваших сотрудников будет падать
"К сервису заказов в корзине нужно добавить текстовое поле для промокода, а в базе сделать новую табличку с такими-то полями" — плохо
"Нам нужно добавить возможность использовать промокод, подумай как это можно сделать" — хорошо
Возвращаясь к вопросу про найм людей умнее себя. Одна из проблема менеджера заключается в том, что он рассматривает исполнителей как продолжение своих рук. Никого нельзя засунуть себе в голову, а менеджер долго думал над задачей, он декомпозировал ее в голове до мельчайших подробностей и поэтому ему кажется, что он должен максимально передать это знание исполнителю. И начинается подробный рассказ, как именно надо сделать то или иное, при этом из вида часто упускается именно исходная проблема
Лучше всего расслабиться и принести именно проблему в ее исходном виде. И потратить усилия на то, чтобы объяснить, зачем именно мы это делаем и куда мы идем, а реализацию оставить на откуп тому, кто непосредственно будет это делать. На самом деле этим мы убиваем сразу двух зайцев: не тратим ресурсы на перекладывание информации из одной головы в другую, тем самым избегая ее искажения и повышаем мотивацию человека, который будет делать задачу. Люди чувствуют когда им доверяют и позволяют реализоваться как профессионалам и ценят это. От менеджера же требуется лишь доверять своим сотрудникам. Микроменеджеров никто не любит и эффективность ваших сотрудников будет падать
"К сервису заказов в корзине нужно добавить текстовое поле для промокода, а в базе сделать новую табличку с такими-то полями" — плохо
"Нам нужно добавить возможность использовать промокод, подумай как это можно сделать" — хорошо
Тестовые задания
Интересно, откуда пошло мнение, что можно давать тестовые из рабочих задач и это типа экономия на использовании беплатной рабочей силы? Код должен поддерживаться, код должен жить и код должен соответствовать контексту. Поэтому крайне маловероятно, что тестовое задание на несколько часов может быть выдернуто из воркфлоу и возвращено туда решенным.
Код в статике никому не нужен, на гитхабе огромное количество хорошего мертвого кода. Главное в процессе — это развитие.
Интересно, откуда пошло мнение, что можно давать тестовые из рабочих задач и это типа экономия на использовании беплатной рабочей силы? Код должен поддерживаться, код должен жить и код должен соответствовать контексту. Поэтому крайне маловероятно, что тестовое задание на несколько часов может быть выдернуто из воркфлоу и возвращено туда решенным.
Код в статике никому не нужен, на гитхабе огромное количество хорошего мертвого кода. Главное в процессе — это развитие.
Автоматизация
Сегодня капитанский пост. Про автоматизацию.
Вкратце мой посыл таков: автоматизируй все, что можно
Мне порой кажется странной ситуация с «растущими командами». Это понятно, когда расширяется бизнес и появляются новые направления, которые надо обслуживать. Но зачастую я встречаю ситуацию: «мы тут купили ещё сто серверов, нам нужен ещё один админ, старый уже не справляется». То есть у вас 100 однотипных серверов, гайз, и вы рулите ими руками админов, платите им зарплату, а еще и про бас фактор тоже забывать не стоит.
С увеличением количества серверов без увеличения функций, количество людей, обслуживающих эти сервера, увеличиваться не должно.
У меня в вакансии, кстати, есть пункт "понимать, почему не стоит ходить на сервера по ssh" и недавно один товарищ написал в отклике "все технологии, описанные вами. я готов изучить, но не понимаю, почему не стоит ходить на сервера по ssh"
Потому и не стоит, чувак, на сервера должны ходить скрипты, которыми ты мудро управляешь
Сегодня капитанский пост. Про автоматизацию.
Вкратце мой посыл таков: автоматизируй все, что можно
Мне порой кажется странной ситуация с «растущими командами». Это понятно, когда расширяется бизнес и появляются новые направления, которые надо обслуживать. Но зачастую я встречаю ситуацию: «мы тут купили ещё сто серверов, нам нужен ещё один админ, старый уже не справляется». То есть у вас 100 однотипных серверов, гайз, и вы рулите ими руками админов, платите им зарплату, а еще и про бас фактор тоже забывать не стоит.
С увеличением количества серверов без увеличения функций, количество людей, обслуживающих эти сервера, увеличиваться не должно.
У меня в вакансии, кстати, есть пункт "понимать, почему не стоит ходить на сервера по ssh" и недавно один товарищ написал в отклике "все технологии, описанные вами. я готов изучить, но не понимаю, почему не стоит ходить на сервера по ssh"
Потому и не стоит, чувак, на сервера должны ходить скрипты, которыми ты мудро управляешь
Про nocode
Современный тренд на nocode-платформы меня прям умиляет. Я вспоминаю начало 2000-х и кучу CMS, которые должны были похоронить профессию программиста как факт. 15 лет прошло и до сих пор хоронят. Надо признать пару очевидных вещей: во-первых, из nocode-истории можно собрать только то, что задумал разработчик. Все хотят повторения чуда Lego, из которых реально можно собрать что угодно, но чуда не случается. А во-вторых, для использования nocode-платформ нужно быть технически подкованным человеком. Все истории успеха, все продукты, собранные на них, были собраны людьми, так или иначе имевших опыт в IT: разработчиками или админами.
Я разговаривал с "обычными пользователями", у них реально сносит крышу от сложности, они просто не понимают предметки. А программисты всегда могут накодить себе нужный обвес рядом и потребность в nocode-платформе резко снижается.
Так что это очередной булшит, революции не произойдет
Современный тренд на nocode-платформы меня прям умиляет. Я вспоминаю начало 2000-х и кучу CMS, которые должны были похоронить профессию программиста как факт. 15 лет прошло и до сих пор хоронят. Надо признать пару очевидных вещей: во-первых, из nocode-истории можно собрать только то, что задумал разработчик. Все хотят повторения чуда Lego, из которых реально можно собрать что угодно, но чуда не случается. А во-вторых, для использования nocode-платформ нужно быть технически подкованным человеком. Все истории успеха, все продукты, собранные на них, были собраны людьми, так или иначе имевших опыт в IT: разработчиками или админами.
Я разговаривал с "обычными пользователями", у них реально сносит крышу от сложности, они просто не понимают предметки. А программисты всегда могут накодить себе нужный обвес рядом и потребность в nocode-платформе резко снижается.
Так что это очередной булшит, революции не произойдет
Часто очень мелькает вопрос: а как отличить миддла от сеньора? Как определить мой грейд?
Я для себя определил очень простую шкалу:
- джун не знает как делать
- миддл знает как делать
- сеньор знает как не делать
Я для себя определил очень простую шкалу:
- джун не знает как делать
- миддл знает как делать
- сеньор знает как не делать
Не бывает больше одной срочной задачи
Это бессмыслица уже по своей форме даже, не только по сути. Всегда есть градация приоритетов. Вот, например, как это сделано в гугле. Задача уровня Р0 (то есть имеющая максимальный приоритет) критична для бизнеса и все ресурсы должны быть брошены на ее выполнение. У таких задач должно быть явно обозначенное время реакции и четко прописанный регламент. Команда не должна выбирать и думать, какая из Р0 приоритетнее🤔
Поэтому когда приходят два менеджера со "срочными" задачами, и это не бизнес-критикал, а просто горит, то надо понимать: либо будет сделана одна, но хорошо. Либо обе, но хуево.
И об этом надо говорить сразу и делегировать принятие этого решения именно менеджерам, горит-то у них. Зачастую, кстати, сделать обе, но хуево — это вариант, который устраивает все стороны. И можно сделать не тупо хуево, а в соответствии с принципом прогрессивного джипега и оставить возможность доделать до 100% уже имея какой-то работающий прототип на руках
Это бессмыслица уже по своей форме даже, не только по сути. Всегда есть градация приоритетов. Вот, например, как это сделано в гугле. Задача уровня Р0 (то есть имеющая максимальный приоритет) критична для бизнеса и все ресурсы должны быть брошены на ее выполнение. У таких задач должно быть явно обозначенное время реакции и четко прописанный регламент. Команда не должна выбирать и думать, какая из Р0 приоритетнее🤔
Поэтому когда приходят два менеджера со "срочными" задачами, и это не бизнес-критикал, а просто горит, то надо понимать: либо будет сделана одна, но хорошо. Либо обе, но хуево.
И об этом надо говорить сразу и делегировать принятие этого решения именно менеджерам, горит-то у них. Зачастую, кстати, сделать обе, но хуево — это вариант, который устраивает все стороны. И можно сделать не тупо хуево, а в соответствии с принципом прогрессивного джипега и оставить возможность доделать до 100% уже имея какой-то работающий прототип на руках
Google for Developers
Issues | Google Issue Tracker | Google for Developers
Learn more about the most common issues you might encounter, with a detailed list of issue types and denoscriptions.
Про рутину
Часто слышу, люди жалуются: работа неинтересная, рутина завалила, начинаю выгорать, жизнь не мила. Я нашего брата-ойтишника имею в виду конечно.
Ну вот как так? Если отбросить очевидный вариант "ты ж не дерево, встань и поменяй работу", почему люди ничего с этим не делают? Я рутину люблю например. Много рутинных действий — это простор для автоматизации. Можно начать оптимизировать, писать кодогенераторы, ямлогенераторы, хелмогенераторы, ввести метрики и явно замерить эффект от своих действий. Придти с ним к бизнесу и гордо сказать "воть!"
Ну, по возможности, надо избегать, конечно, таких мест, где нельзя придти и сказать "воть!", потому что всем пофиг или сначала надо продраться через чудовищную стену бюрократии. В этом случае надо, конечно, вспоминать, что ты не дерево
Часто слышу, люди жалуются: работа неинтересная, рутина завалила, начинаю выгорать, жизнь не мила. Я нашего брата-ойтишника имею в виду конечно.
Ну вот как так? Если отбросить очевидный вариант "ты ж не дерево, встань и поменяй работу", почему люди ничего с этим не делают? Я рутину люблю например. Много рутинных действий — это простор для автоматизации. Можно начать оптимизировать, писать кодогенераторы, ямлогенераторы, хелмогенераторы, ввести метрики и явно замерить эффект от своих действий. Придти с ним к бизнесу и гордо сказать "воть!"
Ну, по возможности, надо избегать, конечно, таких мест, где нельзя придти и сказать "воть!", потому что всем пофиг или сначала надо продраться через чудовищную стену бюрократии. В этом случае надо, конечно, вспоминать, что ты не дерево
В продолжение темы Infrastructure as Software
Не так давно я писал пост про возрастающую сложность YAML-манифестов и про то, что рано или поздно мы придем к концепции описания инфраструктуры кодом. То есть декларативное описание становится слишком сложным и нам уже физически необходимо использовать стару-добрую императивную логику. Вот и первая ласточка в этом направлении (может и не первая, но до меня пока только эта долетела)
Встречайте Cloud Development Kit for Kubernetes
Идея ровно такая, как я писал в упомянутом посте. Генерация шаблонов из кода. На данный момент поддерживаются python, java, typenoscript и javanoscript. Идея проста до безобразия и именно тем и привлекательна. Буду пробовать обязательно, по результатам отпишусь
#полезняшки
Не так давно я писал пост про возрастающую сложность YAML-манифестов и про то, что рано или поздно мы придем к концепции описания инфраструктуры кодом. То есть декларативное описание становится слишком сложным и нам уже физически необходимо использовать стару-добрую императивную логику. Вот и первая ласточка в этом направлении (может и не первая, но до меня пока только эта долетела)
Встречайте Cloud Development Kit for Kubernetes
Идея ровно такая, как я писал в упомянутом посте. Генерация шаблонов из кода. На данный момент поддерживаются python, java, typenoscript и javanoscript. Идея проста до безобразия и именно тем и привлекательна. Буду пробовать обязательно, по результатам отпишусь
#полезняшки
Telegram
Happy Devops
Infrastructure as Software
Мир инфраструктуры движется (хочется написать, что в сраное говно, но нет) в сторону упрощения управления сущностями. А сложность самих сущностей сильно возрастает. И то, что казалось шагами к упрощению, эту сложность как раз увеличивает…
Мир инфраструктуры движется (хочется написать, что в сраное говно, но нет) в сторону упрощения управления сущностями. А сложность самих сущностей сильно возрастает. И то, что казалось шагами к упрощению, эту сложность как раз увеличивает…
В продолжении поста про рутину
Мне написали несколько человек про вторую часть, в частности про "всем пофиг"
Зачастую невнимание бизнеса к недостаткам в Operations, да и в разработке, обусловлены не тем, что они такие плохие, а тем, что они гораздо больше погружены в бизнес-процессы, а если техническая команда выдает какой-то приемлемый результат, то и лезть туда незачем. Это зона ответственности СТО, а они, к сожалению, не всегда бывают компетентны. В результате проблемы начинают замечать тогда, когда это уже превратилось в снежный ком. Но всегда есть шанс взять инициативу в свои руки, ввести метрики, найти проблемные места и оптимизировать их. Бизнес очень любит цифры, если придти к нему не с истерикой вида "аа, все плохо", а показать конкретные цифры, озвучить результаты своего исследования и предложить пути оптимизации, то в большинстве случаев это сработает. Меньшинство включает в себя случаи, когда реально пофиг (это очень плохо) и когда все это обвешано космическим количеством бюрократии (привет банки, бодишопы и всякий энтерпрайз). В этом случае, конечно, надо смазывать лыжи
Вообще, придание собственной ценности тому проекту, с которым ты работаешь, очень добавляет мотивации и защищает от выгорания. Вот это ощущение, когда ты действительно можешь что-то менять в рамках своих компетенций, оно очень крутое
Мне написали несколько человек про вторую часть, в частности про "всем пофиг"
Зачастую невнимание бизнеса к недостаткам в Operations, да и в разработке, обусловлены не тем, что они такие плохие, а тем, что они гораздо больше погружены в бизнес-процессы, а если техническая команда выдает какой-то приемлемый результат, то и лезть туда незачем. Это зона ответственности СТО, а они, к сожалению, не всегда бывают компетентны. В результате проблемы начинают замечать тогда, когда это уже превратилось в снежный ком. Но всегда есть шанс взять инициативу в свои руки, ввести метрики, найти проблемные места и оптимизировать их. Бизнес очень любит цифры, если придти к нему не с истерикой вида "аа, все плохо", а показать конкретные цифры, озвучить результаты своего исследования и предложить пути оптимизации, то в большинстве случаев это сработает. Меньшинство включает в себя случаи, когда реально пофиг (это очень плохо) и когда все это обвешано космическим количеством бюрократии (привет банки, бодишопы и всякий энтерпрайз). В этом случае, конечно, надо смазывать лыжи
Вообще, придание собственной ценности тому проекту, с которым ты работаешь, очень добавляет мотивации и защищает от выгорания. Вот это ощущение, когда ты действительно можешь что-то менять в рамках своих компетенций, оно очень крутое
Telegram
Happy Devops
Про рутину
Часто слышу, люди жалуются: работа неинтересная, рутина завалила, начинаю выгорать, жизнь не мила. Я нашего брата-ойтишника имею в виду конечно.
Ну вот как так? Если отбросить очевидный вариант "ты ж не дерево, встань и поменяй работу", почему…
Часто слышу, люди жалуются: работа неинтересная, рутина завалила, начинаю выгорать, жизнь не мила. Я нашего брата-ойтишника имею в виду конечно.
Ну вот как так? Если отбросить очевидный вариант "ты ж не дерево, встань и поменяй работу", почему…
Только мы успели проговорить про VSCode в браузере, как Майкрософт выкатил офигенную логичную фичу. Открываете любой репозиторий, нажимаете "." (точку) и вас кидает в открытый VSCode (открывается он на сайте https://github.dev). Отличий от предыдущего варианта вагон. Во-первых, это полнофункциональная среда разработки с возможностью выбрать цветовую тему, установить расширения, настроить шрифты и все такое. Во-вторых, ваши изменения сразу попадают на гитхаб с возможностью сделать пулл-реквест, если вы внесли правки в чужой репозиторий и сделать прямой коммит, если вы работаете в своем. В сочетании с GitHub Actions это отличная возможность поправить что-то по-быстрому с любого устройства и сразу запустить пайплайн. Ну и в-третьих используя Setting Sync вы можете иметь единообразно настроенную среду разработки, опять-таки, на любом устройстве
#полезняшки
#полезняшки
Telegram
Happy Devops
VS Code в браузере
В сегодняшние #полезняшки попала совершенно чумовая, на мой взгляд, штука :)
Что получится, если скрестить 1С и гитхаб? Шутка, не тот 1С, о котором вы подумали. А просто добавляем к домену гитхаба 1s и получаем VS Code прямо в вашем в…
В сегодняшние #полезняшки попала совершенно чумовая, на мой взгляд, штука :)
Что получится, если скрестить 1С и гитхаб? Шутка, не тот 1С, о котором вы подумали. А просто добавляем к домену гитхаба 1s и получаем VS Code прямо в вашем в…
Про отсутствие эго
В рабочем процессе нужно выключать свое эго. И решения стоит принимать не исходя из своей предпочтений, а из того, что двинет ваш проект вперед. Это все относится к "попробовать новые клевые штуки", "я не буду делать, потому что мне не нравится", "я устал от рутины" и все такое. Когда исключаешь "Я" из этого потока и начинаешь принимать решения исходя из business value, то работать становится
а) интереснее
б) эффективнее
Эго в рабочем процессе — это всегда конфликт. Ровно потому, что наши собственные стремления могут расходиться с требованиями бизнеса и надо таки выбирать бизнес. Я так уверенно говорю, потому что я был и на другой стороне баррикад. У меня был опыт запуска своего бизнеса, в который приходилось нанимать людей и как руководитель, я очень хорошо понимал, чего я хочу от сотрудников. Потом, вернувшись обратно в найм, я вспомнил про все вот эти свои хотелки и стал применять их уже в роли наемного работника. Это работает офигенно. Договариваться стало проще, реализовываться стало проще, работать стало интереснее. И когда я попытался суммировать как-то этот опыт, то пришел как раз к очень простому выводу: я выбросил эго и стал думать не про то, как мне хочется, а про то, как это будет полезно. А в итоге в выгоде остаются все, идеальный пример win-win стратегии
В рабочем процессе нужно выключать свое эго. И решения стоит принимать не исходя из своей предпочтений, а из того, что двинет ваш проект вперед. Это все относится к "попробовать новые клевые штуки", "я не буду делать, потому что мне не нравится", "я устал от рутины" и все такое. Когда исключаешь "Я" из этого потока и начинаешь принимать решения исходя из business value, то работать становится
а) интереснее
б) эффективнее
Эго в рабочем процессе — это всегда конфликт. Ровно потому, что наши собственные стремления могут расходиться с требованиями бизнеса и надо таки выбирать бизнес. Я так уверенно говорю, потому что я был и на другой стороне баррикад. У меня был опыт запуска своего бизнеса, в который приходилось нанимать людей и как руководитель, я очень хорошо понимал, чего я хочу от сотрудников. Потом, вернувшись обратно в найм, я вспомнил про все вот эти свои хотелки и стал применять их уже в роли наемного работника. Это работает офигенно. Договариваться стало проще, реализовываться стало проще, работать стало интереснее. И когда я попытался суммировать как-то этот опыт, то пришел как раз к очень простому выводу: я выбросил эго и стал думать не про то, как мне хочется, а про то, как это будет полезно. А в итоге в выгоде остаются все, идеальный пример win-win стратегии
Все, что идет в комплекте с JDK — прекрасные, удобные, стабильно работающие вещи: javac, jar, javadoc, java. Наверное, потому что люди, программирующие JDK, на Джаве не пишут.
(с) Тонский
(с) Тонский