Pull to refresh
22
0
Карен Товмасян @v_sadist

Архитектор систем различной степени тяжести

Send message

Господин Автор, вот уже почти 10 лет я жду вторую часть!

Спасибо за добрые слова! <3

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

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


Раскройте больше деталей, а я постараюсь прикинуть к носу. :)

Спасибо! Помню, что в ес2 завезли, насчет других не знал.

Уволили очень просто — предложили несколько окладов и сказали, что в услугах более не нуждаются.
По оф версии директор по инфраструктуре мыслил классическим подходом со всеми этими чейндж реквестами, многоуровневой валидацией и тд, и якобы не мог переобуться в супергибкий девопс. Потому его убрали и нашли дядю, который знает все модные подходы и технологии.
Проблема в том, что девопс подразумевает тесное взаимодействие. Можно сколько угодно совать тулзы по автоматизации, деплоить код по нажатии кнопки в джире, но blameless culture в мозгах некомпетентных (мягко говоря) управленцев не ложилась никак.
А по неоф данным, старый (изначальный) директор по инфре был слишком упертый и слишком яростно защищал свою команду (т.е. меня и моих коллег), вот его и турнули, но это уже условности.
А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.
Сидели мы, бед не знали, как нашего начальника (директор по инфраструктуре) убрали, и наняли «директора по девопсу». Дядя пришел, раздал всем опросники с вопросами про культуру и вот это вот все, поставил задачу изучать модные тулзы по автоматизации и так далее… и ничего из этого не вышло, т.к. менеджменту удобнее было держать огороженные друг от друга отделы инфраструктуры, тестировщиков и разработки. Никаких объединений над общей задачей, никакой blameless культуры (когда случался факап, вместо решения проблемы искали крайних, которых поставить проблему решить, а потом всенародно отчитывали. Про «проблема не на нашей стороне» вообще молчу — классика.
Закончил девопс дядя тем, что когда из хэд офиса уволили единственного хелпдеска, сидел и людям почту настраивал.
А затем и его уволили и наняли «директора по инфраструктуре».
Уважаемый Keks650, боюсь проблема компании не в самом Скрам, а в идиотизме управленцев (то что вы описали, кроме как идиотизмом назвать нельзя). В Скраме есть стори поинты описывающие сложность задачи — при чем тут вообще «время»?.. Во-вторых половину задач в нашем беклоге генерируем мы сами, не ожидая ничего от бизнеса. И в конце концов в Agile (да и не только) есть такое прекрасное слово «Нет, мы не будем это делать».
Но боль вашу прекрасно понимаю, у нас тоже так «удачно» внедрили «Девопс».
Касательно прав на файлы в линукс, есть небольшое замечание — other != кто угодно.
Например, если вы сделаете права на файл 007, то файлом смогу пользоваться кто угодно КРОМЕ группы и владельца файла (это по понятным причинам не касается рута).
А в целом статья прекрасная :)
Вот ДА!
Надо было сделать некий интерфейс для разрабов, чтобы те могли создавать и копировать схемы оракла из прода в дев. Чем писать свой велосипед — сделал несколько джобов, которые читали вводные данные и запускали скрипты.
Ну все довольно прозаично.
Практика моей вышки (а учился я далеко не в ИТ вузе) показала, что прогеры выпущенные моей альмаматер показали себя довольно сильно подготовленными в области ООП, алгоритмики и математических методов (а математика для разраба — наше все). Могу только представить, каких монструозных специалистов готовят такие ВУЗы как МГТУ Москвы, МИРЭА и Новосибирские технические ВУЗы.
Что касается инженерного дела — причины тут близкие, но немного переиначенные. Когда речь идет о внедрении ИТшной вундервафли, западная контора наймет под это дело специального человека (либо на рынке найдет, либо интегратор предоставит). В нашем же случае что-то большое периодически внедряется своими силами, и хорошо если человека предварительно на курсы отправят, а не «учись сам». Подобные ограничения очень сильно развивают инженерное мышление.

А вот слабые стороны — это технологии. К сожалению, нам не всегда выпадает возможность работать с новейшей техникой и ПО (лично я учил С++ на код блокс, и только на 4ом курсе я открыл для себя вижуал студио). Это же применимо и к большинству компаний, где latest and greatest открыт только для очень богатых энтерпрайзов и для интеграторов.
Буду рад, если вы расскажете об ином способе точных измерений возможностей сотрудника.

С какой стати группа людей оценивает одного человека?


С той, что люди в команде оценивают друг друга. Не смежных, не менеджмент, никто иной как член команды.

Что это дает кроме лжи или же наоборот, повода для расстройства?


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

Это используется как критерий оценки качества работы?


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

Да что, других способов оценивать работу нет что ли?


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

Или это используется как критерий оценки самого человека?


Личные качестве/софт скиллы так же оцениваются. Так например оценивают насколько человек делится экспертными знаниями и коммуникативные навыки.

Но зачем?

Причины означены выше.
При всем уважении — нагуглил как-то статистику ИТ зарплат за последние 10 лет в Нидерах и сравнил с количеством приезжих из восточной европы. Данные не кореллируют. Моя зарплата выше моих местных коллег по цеху (даже при условии того, что их опыт в цифрах больше).
У меня к вам встречный вопрос — вы способны создать конкуренцию ордам бегущих из России инженеров? (Лично я придерживаюсь мысли, что в России самые сильные инженеры и разработчики во всем мире).
Вы мне напомнили мою тур поездку в Испанию — тогда мы с другом абсолютно не пользовались путеводителями и отзывами туристов, а заходили в самое захолустное кафе в районе, где арендовали жилье (и это был далеко не центр). Местные рассказывали нам о бесплатных музеях (даже без Мадрид карты) и смотровой площадке, откуда весь город как на ладони. А после пары сангрий мы слушали истории о неправильной экономической политике государства, о сепаратистах из Каталонии (или федеральных ублюдках из Мадрида — когда мы были в Барсе).
Никто вам не расскажет о жизни местных в стране лучше коренного жителя.
Позже я стал изучать вопрос — почему наша команда решает задач на одинаковое количество стори поинтов, при этом стала внедрять всякого на большее количество… как бы это сказать «value».
Во время проведения ретроспективы я озвучил этот вопрос коллегам. Мы пришли к выводу, что за счет улучшения, упрощения и автоматизации различных процессов, мы стали их оценивать на меньше количество стори поинтов.
Вот пример — для простоты оценки мы взяли за правило, что поднять виртуальный сервер (вин или лин), выбрать и назначить ему ипшник, поставить необходимое ПО или роль, настроить бекапирование и добавить сервер в нагиос — это 1 очко.
Через 2 месяца все — от выдачи ипшника до накатывания роли и бекапов — у нас это делалось автоматически. А мониторинг перешел в ответстенность нашим ребятам из операций. В итоге — трудозатрат и effort на эту задачу стало расходоваться меньше, и теперь мы оцениваем задачу «поднять сервер» на 0.5 очков.
Что касается умышленного завышения — мы применяли немного иной подход. Поскольку я в команде был новым, ребята должны были проводить мне краткий тренинг, как все устроено, где документация и тд. Чтобы эта работа была учтена, мы создали задач в стиле «обучить Карена вот этому», «обучить Карена правилам документирования операций на проде», «обучить Карена реестру сетей и ИП адресов». Каждая история имела определенную оценку.
А метод оценки стандартных задач, которые у одного были легкими, а у другого сложными — мы брали среднее значение. Так задача, которая заняла у одного человека 1 очко, а у другого 5 по причие отсутствия опыта, в итоге получала 3 очка. Эксперт же брал на себя ответственность выполнить задачу вместе с новичком, чтобы у него появился необходимый опыт.
Разница лишь в том, что после ситуации в спойлере я всегда готов к такому сценарию. Более того — этот пример дополнительно мотивирует меня строить очень надежные, удобные в эксплуатации и безопасные решения.
Речь не об опустить — я не получаю никакого удовольствия от унижения кого-либо в принципе.
Речь о том, что если человек претендует на открытость — я жду именно этого. Но признаю, поступок некрасивый, и более я подобного ни на одной демонстрации не повторял.
в таком случае надо просто взять себя в руки и учиться. Мне очень помог LinuxAcademy
Что на мой взгляд абсолютно некорректно. Сидят виндовые инженеры, которые SCCM в глаза не видели и пакеты через GPO устанавливают. Устраивается на работу в команду сеньор которые на SCCM собаку съел, за 2 неделю делает ПоК, еще через 2 недели — пилота. А ему на оценке 3 поставили — типа не переживай бро, со временем будет лучше.
А я и не говорил, что это плохо :) Пока критика конструктивна, она всегда полезна. Разница лишь в том, что в моем случае, новичок гарантированно получит оценку ниже, просто потому что он новичок
На одной конфе докладчик рассказывал про мониторинг. Был задан вопрос залу — кто НЕ мониторит репликацию мускула. Потом у кого отваливалась репликация и они об этом узнавали, когда отваливался мастер мускул. Сколько времени лежала репликация. Когда в зале оставалось несколько поднятых рук докладчик начинал браваду, мол вы парни столько денег из-за факапа потеряли, а вот как можно проверять и т.д
Люди не чувствовали себя униженными — разве что публичное признание своих косяков является унижением.

Information

Rating
Does not participate
Location
Haarlem, Noord-Holland, Нидерланды
Date of birth
Registered
Activity