Мой алгоритм выхода из нештатной ситуации: 0) Заранее обложить все сервисы мониторингом, чтобы как можно раньше заметить, где и что упало. 1) Собственно локализовать проблему (сервис и его конкретный компонент) 2) Бросив все силы на решение, вставить костыль 3) Пока костыль работает, продумать решение по "best practice" 4) Исправить проблему окончательно и проверить, что полученное решение ничего не ломает
Хороший ответ. Хороший подход. Не хватает только одного - Как руководителю сделать так, чтобы команда сделала все так как написано у Вас в ответе. Что именно надо сделать руководителю чтобы было вот так. Спасибо!
@@aleksandrmelnichuk1373 +100000. В этом проблема, большенство людей приходят на работу за зарплатой. Что этот мониторинг был, что бы специалисты могли быстро найти проблемный участок кода, нужно впороть кучу времени на организцию всего и вся
Как стать техническим директором? Надо чтоб друг позвонил и предложил стать техническим директором :) вообще видео полезное, но название кликбейтное. Никакого универсального рецепта нет.
Очень познавательное интервью. Согласен с 80% сказанного. Александру большое спасибо - несколько полезностей в копилку. По поставленной ситуации отвечу так: как мне кажется в проектах подобного уровня во главе угла стоит клиент и очень важно 1. шагом №1 скоординировать все службы первой линии поддержки, чтобы они знали о возможных звонках и обращениях и сформировать общую тактику и стратегическое видение решения проблемы. 2. Определить возможный SLA 3: Сообщить всем участникам технической команды о проблеме и тут конечно Александр все сказал - методология идеальна. 4. Обеспечить поддержку лояльности клиента после решения проблемы через обратную связь 5. Провести анализ ситуации и решить как сделать так:, чтобы подобное не повторялосью. 6. Выдохнуть. )
Ну правильно, руководитель то не должен писать код, он должен управлять людьми, которые умеют писать код :-) Цель быть техническим директором или программистом не очень круто, это всё наёмные сотрудники и всегда есть потолок по деньгам, а сливки снимают владельцы бизнеса. По идее технические специальности и менеджерские - это проходные этапы к своему бизнесу. Даже мелкий бизнес может приносить больше денег, чем зарплата топовых технических спецов. А как ни крути, а цель жизни сводится к зарабатыванию денег. Видео интересное для расширения кругозора и бесплатного получения чужого опыта. Спасибо.
0. скоординировать общую работу: например, завести чат в слаке/телеграме/матермосте куда будут складываться все найденные факты 1. оценить, когда проблема появилась и масштаб 2. сделать оповещение и посадить отдельного человека отвечать на запросы извнем 3. соотнести это с тем кто, когда делал изменения, при этом учесть: 3.1. время начало проблемы могли не правильно понять 3.2. какие-то измения могли быть сделаны "втихую" 4. основной упор сделать на изменениях наиболее близких ко времени начала проблемы 5. отследить проблемные запросы и пробежаться по всему стэку технологий на каком уровне вылазит проблема
Хороший ответ! Понравилось про отдельный канал - у нас канал General в slack закреплен за форс мажорными ситуациями и если кто то видит проблему с ресурсом - пишет туда и все начинают подключаться к решению. Остальные пункты тоже хорошо. Не хватает небольшой "вишенки на торте". Ну и работ после ликвидации последствий аварийной ситуации. Спасибо!
Как правило, перед тем как узнаешь, кто сломал, приходится найти причину, которая вызвала внештатную ситуацию, а это самое сложное. Дальше придумать, как её устранить, а потом уже искать виновных. В общем, наказывать виноватых и поедать их потом не в наших правилах :-). Мы стремимся к тому, чтобы люди у нас работали и работали с удовольствием, совершенствовали свои знания и навыки. Поэтому тут важно скорее сделать так, чтобы второй раз никто на грабли не наступал, чем прилюдно наказать наступившего. Спасибо.
Если возникает проблема такого уровня, я бы всех оповестил и объявил награду тому (тем), кто найдет руткоз и/или придумает лучший фикс в кратчайший срок. Если компания большая, то вполне может позволить выдать награду в виде, скажем, 0.5 оклада или же какое-то коичество дополнительных day off, или иметь что-то более креативное в заначке на такой случай (самое удобное кресло или тур в Альпы, что угодно, способное качественно мотивировать).
Награда за фикс безусловно хороший вариант! С премиальным фондом у нас все хорошо и разумеется человек, выявивший проблему получил денежную премию. Это совершенно верно. Но награда это не самое главное в процессе выявления проблемы. Спасибо.
я даже не программист, пока что, но что если сперва вернуть предыдущую рабочую версию, гит хаб к примеру это позволяет, потом разделить на логический функционал весь не работающий код на людей, а то все кинутся искать ошибку в одном месте где её нет.
К сожалению, не всегда можно откатить любые изменения. Так же делить отрезки функционала на людей - не самое благодарное занятие. Людей много и я не знаю кто из них что знает лучше. Только сами люди могут правильно поделиться. Спасибо.
Сложные ситуации, как правило, создают не железо и не софт, а люди. Поэтому необходимо собрать всех участников последних изменений в проекте и в коллегиально-авторитарном режиме назначить ответственных за определенный участок проекта для последующего выявления ошибок)) Ну и не забыть дать подзатыльники всем виноватым))
Коллегиально-авторитарный режим! В общем расстрелять виноватых. А чинить то кто будет? И работать потом? :-)))) На подзатыльниках далеко не уедешь. Спасибо за ответ!
Российский подход - если охранник допустил воровство в супермаркете, то нужно его выгнать и нанять нового. Ну наказали типа. Правильный подход - дать ему второй шанс, из-за чувства вины он будет более внимательный и у него есть уже опыт по обнаружению воровства, по любому он лучше нового охранника. У самых суровых родителей, практикующих наказание, вырастают очень изворотливые дети обманщики. :-)
Для поиска ошибки формируется общий шаблон поиска ошибки, чтобы любой член команды мог по нему провести анализ возникшей проблемы. 0) Если есть тесты, то запуск тестов сразу может выявить ошибку (если они при сборке не запускались) 1) Анализ логов веб-сервера 2) Анализ логов БД 3) Анализ последних коммитов По возможности воспользоваться полнотекстым поиском по логам. Возможно даже сформировать таким образом, автоматический анализ состояния системы.
Спасибо за ответ. Несколько комментариев: Тесты конечно ДА, но это скорее предотвращение ошибки. В нашем случае они помогли бы - но так как был релиз сервисной функции их не запускали. Наша ошибка. Анализ логов - тоже ДА. Вопрос только был немного в другом: Вы руководитель и есть команда. Случилась внештатная ситуация - дальше что вам делать как руководителю? Что нужно сделать до ситуации чтобы ее предотвратить, что сделать во время, и что сделать потом. Спасибо.
Мой алгоритм выхода из нештатной ситуации:
0) Заранее обложить все сервисы мониторингом, чтобы как можно раньше заметить, где и что упало.
1) Собственно локализовать проблему (сервис и его конкретный компонент)
2) Бросив все силы на решение, вставить костыль
3) Пока костыль работает, продумать решение по "best practice"
4) Исправить проблему окончательно и проверить, что полученное решение ничего не ломает
Хороший ответ. Хороший подход. Не хватает только одного - Как руководителю сделать так, чтобы команда сделала все так как написано у Вас в ответе. Что именно надо сделать руководителю чтобы было вот так. Спасибо!
Станислав, тут ещё пункт 5 должен быть - 5) добавить в базу знаний. А вообще ваши пункты очень схожи с тем, что уже давно описано в ITIL
@@aleksandrmelnichuk1373 +100000. В этом проблема, большенство людей приходят на работу за зарплатой.
Что этот мониторинг был, что бы специалисты могли быстро найти проблемный участок кода, нужно впороть кучу времени на организцию всего и вся
Как стать техническим директором? Надо чтоб друг позвонил и предложил стать техническим директором :) вообще видео полезное, но название кликбейтное. Никакого универсального рецепта нет.
"Никакого универсального рецепта нет." +1
Очень познавательное интервью. Согласен с 80% сказанного. Александру большое спасибо - несколько полезностей в копилку.
По поставленной ситуации отвечу так: как мне кажется в проектах подобного уровня во главе угла стоит клиент и очень важно
1. шагом №1 скоординировать все службы первой линии поддержки, чтобы они знали о возможных звонках и обращениях и сформировать общую тактику и стратегическое видение решения проблемы.
2. Определить возможный SLA
3: Сообщить всем участникам технической команды о проблеме и тут конечно Александр все сказал - методология идеальна.
4. Обеспечить поддержку лояльности клиента после решения проблемы через обратную связь
5. Провести анализ ситуации и решить как сделать так:, чтобы подобное не повторялосью.
6. Выдохнуть. )
APD: Победил Lev Goncharov
*Подведение итогов конкурса - 22 марта 2018 г.*
спасибо, только щас увидел.
1) Смотрим логи
```
tail -f /var/log/httpd/error_log
```
2) Должны быть git-репы
```
git log -p --since="last 2 days"
```
Подскажите, планируется выкладывать в подкаст-формате эти разговоры где-нибудь на подкастинговых сервисах?
Как стать руководителем в ит - должен позвонить знакомый.)))
Ну правильно, руководитель то не должен писать код, он должен управлять людьми, которые умеют писать код :-)
Цель быть техническим директором или программистом не очень круто, это всё наёмные сотрудники и всегда есть потолок по деньгам, а сливки снимают владельцы бизнеса. По идее технические специальности и менеджерские - это проходные этапы к своему бизнесу. Даже мелкий бизнес может приносить больше денег, чем зарплата топовых технических спецов. А как ни крути, а цель жизни сводится к зарабатыванию денег.
Видео интересное для расширения кругозора и бесплатного получения чужого опыта. Спасибо.
0. скоординировать общую работу: например, завести чат в слаке/телеграме/матермосте куда будут складываться все найденные факты
1. оценить, когда проблема появилась и масштаб
2. сделать оповещение и посадить отдельного человека отвечать на запросы извнем
3. соотнести это с тем кто, когда делал изменения, при этом учесть:
3.1. время начало проблемы могли не правильно понять
3.2. какие-то измения могли быть сделаны "втихую"
4. основной упор сделать на изменениях наиболее близких ко времени начала проблемы
5. отследить проблемные запросы и пробежаться по всему стэку технологий на каком уровне вылазит проблема
Хороший ответ! Понравилось про отдельный канал - у нас канал General в slack закреплен за форс мажорными ситуациями и если кто то видит проблему с ресурсом - пишет туда и все начинают подключаться к решению. Остальные пункты тоже хорошо. Не хватает небольшой "вишенки на торте". Ну и работ после ликвидации последствий аварийной ситуации. Спасибо!
Лев, ваш ответ лучший! Вам достается приз от Александра :) Отправьте, пожалуйста, на почту a.ilina@corp.mail.ru ваше ФИО, полный адрес и телефон
ответил вам с почты, на xyz оканчивается
Прибежать со словами к команде "Найдите мне того, кто все сломал". :D
Крутой мужик, очень интересно смотреть.
Как правило, перед тем как узнаешь, кто сломал, приходится найти причину, которая вызвала внештатную ситуацию, а это самое сложное. Дальше придумать, как её устранить, а потом уже искать виновных. В общем, наказывать виноватых и поедать их потом не в наших правилах :-). Мы стремимся к тому, чтобы люди у нас работали и работали с удовольствием, совершенствовали свои знания и навыки. Поэтому тут важно скорее сделать так, чтобы второй раз никто на грабли не наступал, чем прилюдно наказать наступившего. Спасибо.
Если возникает проблема такого уровня, я бы всех оповестил и объявил награду тому (тем), кто найдет руткоз и/или придумает лучший фикс в кратчайший срок. Если компания большая, то вполне может позволить выдать награду в виде, скажем, 0.5 оклада или же какое-то коичество дополнительных day off, или иметь что-то более креативное в заначке на такой случай (самое удобное кресло или тур в Альпы, что угодно, способное качественно мотивировать).
Награда за фикс безусловно хороший вариант! С премиальным фондом у нас все хорошо и разумеется человек, выявивший проблему получил денежную премию. Это совершенно верно. Но награда это не самое главное в процессе выявления проблемы. Спасибо.
я даже не программист, пока что, но что если сперва вернуть предыдущую рабочую версию, гит хаб к примеру это позволяет, потом разделить на логический функционал весь не работающий код на людей, а то все кинутся искать ошибку в одном месте где её нет.
К сожалению, не всегда можно откатить любые изменения. Так же делить отрезки функционала на людей - не самое благодарное занятие. Людей много и я не знаю кто из них что знает лучше. Только сами люди могут правильно поделиться. Спасибо.
chỗ ngồi
Сложные ситуации, как правило, создают не железо и не софт, а люди. Поэтому необходимо собрать всех участников последних изменений в проекте и в коллегиально-авторитарном режиме назначить ответственных за определенный участок проекта для последующего выявления ошибок)) Ну и не забыть дать подзатыльники всем виноватым))
Коллегиально-авторитарный режим! В общем расстрелять виноватых. А чинить то кто будет? И работать потом? :-)))) На подзатыльниках далеко не уедешь. Спасибо за ответ!
Российский подход - если охранник допустил воровство в супермаркете, то нужно его выгнать и нанять нового. Ну наказали типа. Правильный подход - дать ему второй шанс, из-за чувства вины он будет более внимательный и у него есть уже опыт по обнаружению воровства, по любому он лучше нового охранника. У самых суровых родителей, практикующих наказание, вырастают очень изворотливые дети обманщики. :-)
тема, какстать руковолителем, а разговор о том, как хороша плоская организация, и зачем вообще хотеть расти.
Для поиска ошибки формируется общий шаблон поиска ошибки, чтобы любой член команды мог по нему провести анализ возникшей проблемы.
0) Если есть тесты, то запуск тестов сразу может выявить ошибку (если они при сборке не запускались)
1) Анализ логов веб-сервера
2) Анализ логов БД
3) Анализ последних коммитов
По возможности воспользоваться полнотекстым поиском по логам. Возможно даже сформировать таким образом, автоматический анализ состояния системы.
Спасибо за ответ. Несколько комментариев: Тесты конечно ДА, но это скорее предотвращение ошибки. В нашем случае они помогли бы - но так как был релиз сервисной функции их не запускали. Наша ошибка. Анализ логов - тоже ДА. Вопрос только был немного в другом: Вы руководитель и есть команда. Случилась внештатная ситуация - дальше что вам делать как руководителю? Что нужно сделать до ситуации чтобы ее предотвратить, что сделать во время, и что сделать потом. Спасибо.
Классный!
Копай!