Comments 15
Спасибо за статью, но это скорее не основы DevOps, а переезд ( или как сейчас модно говорить — трансформация ) в DevOps. В статье есть очень путные замечания при разгребании авгиевых конюшен, но очень мало технических подробностей. Для меня интересным был бы вопрос, как тех дир допустил такое в 2018 году, что нет мониторинга, инвентаризации и всей остальной централизации, чай ЛитРес не одностраничник с контактами компании ?
Мне показалось, что основы тут в целом подходят, как термин — по сути — как верно подмечено — это именно трансформация, с базовыми основами всего того, что погружено в философию.
Получилось примерно так — много лет назад один хороший человек всё настроил. А потом, на протяжении следующих лет, каждый, кто прикасался к построенному, или что-то ломал, или не считал нужным актуализировать.
По итогам, мониторинг всё-таки был — частично самописный, частично — загаженный нагиос. Ну а инвентаризация и т.п. — это всё я уже собирал из гуглодоков, каждый кто во что горазд делал :)
Получилось примерно так — много лет назад один хороший человек всё настроил. А потом, на протяжении следующих лет, каждый, кто прикасался к построенному, или что-то ломал, или не считал нужным актуализировать.
По итогам, мониторинг всё-таки был — частично самописный, частично — загаженный нагиос. Ну а инвентаризация и т.п. — это всё я уже собирал из гуглодоков, каждый кто во что горазд делал :)
Про технические подробности я не говорил, кстати, сознательно. На таком этапе всё, что я мог бы рассказать, было бы повторением статей хабра и стека.
В следующем году уже вернусь с чем-то более технически интересным — как мы переходили на Vitess, как внедряли git flow, как разворачивали S3 — будет из чего выбрать уже тему :)
В следующем году уже вернусь с чем-то более технически интересным — как мы переходили на Vitess, как внедряли git flow, как разворачивали S3 — будет из чего выбрать уже тему :)
Почему бы не написать про стек, вышло бы годно. Ресурс известный, нагруженный ( как мне кажется ) и выбор инструментов стека ( почему выбрали одно и отказались от другого ) вполне является доказательством того, что эти самые инструменты при должном подходе держат нагрузку и решают задачи. Не обязательно ваять самописные системы, чтобы писать на хабр.
UFO just landed and posted this here
Я использую следующую методологию по определению сроков:
1. Берем идеальную оценку — обычно она базируется на реальной (то есть базируясь на своем опыте) скорости реализации фичи/проекта для очень хорошо слаженной команды или вообще оценки «за сколько я бы один это сделал» в реалиях близких к идеальным. То есть когда прям «прет».
2. Выбираем множитель — он расположен от Пи до Пи/2. Выбираем по кол-ву неопределенностей в проекте — если все новое, предм. область не ясна, требования не особо расписаны, технологии новые и т.д. — берите Пи. Если все более-менее ровно и уже делали подобное и команда хорошая и требования стабильны и качественны — Пи/2.
3. Умножаем идеальную оценку на множитель — это и есть реалистичная оценка проекта.
Из опыта — если проект начинает превышать множитель Пи от идеала — такой проект имеет вероятность «сходимости» вообще. То есть он скорее всего будет закрыт и в прод не пойдет
1. Берем идеальную оценку — обычно она базируется на реальной (то есть базируясь на своем опыте) скорости реализации фичи/проекта для очень хорошо слаженной команды или вообще оценки «за сколько я бы один это сделал» в реалиях близких к идеальным. То есть когда прям «прет».
2. Выбираем множитель — он расположен от Пи до Пи/2. Выбираем по кол-ву неопределенностей в проекте — если все новое, предм. область не ясна, требования не особо расписаны, технологии новые и т.д. — берите Пи. Если все более-менее ровно и уже делали подобное и команда хорошая и требования стабильны и качественны — Пи/2.
3. Умножаем идеальную оценку на множитель — это и есть реалистичная оценка проекта.
Из опыта — если проект начинает превышать множитель Пи от идеала — такой проект имеет вероятность «сходимости» вообще. То есть он скорее всего будет закрыт и в прод не пойдет
Покажите как выглядит куча сложных проектов в вашем Trello? Он же для этого слабо подходит.
Отличная статья, но я, простите, хотел бы побрюзжать. Как понимать фразу — некро-Nagios и некро-Puppet и начали переход на Zabbix? С учётом того что Заббикс родился на год раньше Нагиоса?
Единственное замечание — я думаю, что слово «DevOps» тут исключительно ради хайпа, а всё остальное — суровая действительность быстро растущего проекта, в котором вовремя не оказалось человека, который хочет навести порядок.
Я был ровно в такой же ситуации, только не техдиром, а рядовым админом. Нас была целая команда, но у нас в компании серверов больше, и росли мы примерно на x1.5-2 в год.
В общем, всё очень знакомо :) Многие вещи прям за живое цепляют
Я был ровно в такой же ситуации, только не техдиром, а рядовым админом. Нас была целая команда, но у нас в компании серверов больше, и росли мы примерно на x1.5-2 в год.
В общем, всё очень знакомо :) Многие вещи прям за живое цепляют
Sign up to leave a comment.
Основы DevOps. Вхождение в проект с нуля