Pull to refresh
34
0
Бочаров Филипп @bocharovf

User

Send message
Годно, совпадает с нашим опытом:
Мы начинали вести постмортемы на wiki, со скриншотами и развернутым описанием — показалось слишком громоздко. Банально никто их потом не читал.
Пришли к выводу, что самое ценное в этой практике — план действий, позволяющий решить проблему системно и избежать повторения.
Сейчас на каждую аварию мы заводим LT/US с датой, контуром и кратким описанием проблемы. В рамках нее создаем задачи на:
1. Временное решение (чтобы быстро исправить ситуацию)
2. Настройку / доработку мониторинга (если мы проморгали проблему)
3. Исследование корневой причины
4. Задачи для системного решения проблемы (по результатам исследования)

Пару раз натыкались на повторение проблемы, так как не успевали реализовать системное решение (откладывали из-за недостатка времени). Это всегда очень обидно :)
Скорее речь идет про довольно однобокое описание факторов — только в контексте kubernetes.

Та же «наблюдаемость» — это широкое понятие и фактор, который следует обеспечить любым (!) приложениям, вне зависимости от архитектуры или того, как они развернуты. Наблюдаемость — это возможность определять внутреннее состояние системы и процессов в ней по выходным данным (метрикам, логам, трейсам).

Для распределенной (микросервисной, SOA) архитектуры это просто необходимость. Без наблюдаемости невозможно (дорого и долго) проводить диагностику ошибок на продуктивной среде. С ее помощью можно решать дополнительные задачи: строить карту ландшафта и зависимостей между системами, контролировать SLA процессов и операций и.т.д
Почему не рассматривали Elasticsearch?
Например oss версию, которая бесплатная и под Apache 2.0?
Как решаете проблему асинхронного взаимодействия между сервисами?
Т.е., например один сервис пишет в очередь MQ/базу данных, а другой читает. Как в этом случае пробрасываете контекст?

Почему взяли Jaeger а не OpenZipkin? Проводили ли какие-то сравнения?

Есть общий стандарт Opentrace

Стандарт называется OpenTracing
Лично меня чрезвычайно напрягает отсутствие каких-либо вменяемых зрелых стандартов по созданию trace ID

А OpenTracing чем не подошел?
Вот есть OpenTracing для Node.js
А вот Jaeger под ноду.
Мне кажется масштаб проблемы с «плохими» CV сильно преувеличен.

Я имею некоторый опыт в отборе и собеседованиях кандидатов на позиции разработчиков. Последнее, что меня волнует — это регистр в котором человек написал желаемую позицию:
Senior java developer -> Senior Java Developer

Вы это серьезно?

Неправильное оформление списков или их отсутствие там, где они нужны

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

Текущее позиционирование и ценности вызывают только вопросы.

PS:
Не хочу заниматься формошлёпством на Django.

Что не так? Человек живым языком сформулировал свои интересы, и если мне нужен стажер — формы клепать на Django, то мы оба сэкономим время.
Остались нераскрытыми вопросы:
1. План собеседования? Как Вы выстраиваете встречу? Сколько она длится?
Ну например:
15 минут — рассказ о проекте
5 минут — уточняющие вопросы кандидата
30 минут — тест
15 мин — обсуждение результатов теста

2. Что Вы читали / смотрели по теме? Что действительно полезным оказалось?
Было бы неплохо добавить выводы (для тех, кому лень смотреть таблички).
Например:
Хотите получать много денег и готовы вкалывать как проклятые — вам сюда…
Хотите проводить больше времени с семьей и работать спокойно за достойные деньги — вам туда…
Спасибо, конечно, но хотелось бы больше конкретики по сабжу — «от старшего разработчика до руководителя отдела»:

  • Что конретно читали / смотрели / пробовали по теме управления командой? (не выпасом котов же единым)
  • Что оказалось полезно, а что нет?
  • Какие ошибки совершили, как исправили?

О — Operation:
На мой взгляд задача тимлида: выстроить рабочий процесс и поддерживать темп разработки.
Он не должен и не может бегать за каждым разработчиком и расписывать ему задачу по часам.

Детализация задачи (включая оценку времени) — это ответственность самого разработчика. Задача тимлида проверить эту детализацию, согласится с ней или попросить скорректировать. Такой подход гораздо лучше «масштабируется» + сразу ясно насколько разработчик понял требования

В случае с junior-ом или новым сотрудником — тимлид может первое время помогать с оценкой или делегировать эту задачу более опытному сотруднику (ментору / наставнику).
Все, что располагается в пирамиде, участвует (влияет) на архитектуру приложения. Да, элементы очень разные, но это не значит, что их нельзя сравнивать между собой. В статье приведена логика, по которой эти принципы расположены один над другим. Вы можете соглашаться или не соглашаться с этой логикой.
Лично мне такая структура помогает принимать решения (см. чек-лист). Надеюсь, она окажется полезной и другим.
Намешали всего в кучу
Куча — это что-то неупорядоченное. А тут как раз наоборот — выстраивается иерархия.
У вас какие-то конкретные возражения по расположению уровней/элементов или Вы против идеи «иерархичности» в целом?
Никто не мешает Вам на отлично зарекомендовавший себя скелет навешивать столько фарша, сколько Вам нужно

Поддерживаю.
Во-первых никто не запрещает вводить дополнительные пункты или подпункты ТЗ.
Во-вторых я лично для некоторых бессмысленных в рамках разработки ПО разделов типа «Требования к упаковке» пишу что-то вроде «По согласованию с клиентом пункт исключен из ТЗ» или «Специальные требования не предъявляются»
Просто шикарная новость!
Теперь есть повод пересесть с диаграмм highcharts на devextreme в своем проекте. Благо они еще и с angular'ом новым интегрируются.
Я отношу такие мысли (если они возникают у меня) к нытью и не зацикливаюсь ;)

Это прекрасно! Только с таким подходом дела и делаются.

Я так понимаю вы оформляете менеджера по продажам в штат. Есть ли смысл в штатной позиции — не смотрели в сторону агентских договоров?
Ну т.е. внешний человек (не сотрудник) чисто на процентах от сделки.

В целом понравилось — давайте еще!
Я только предложил бы сделать уклон в сторону технической части (решения конкретных бизнес-задач). Меньше общих слов — больше дела.
Рекламу «образовательной программы» воспринял как необходимое зло и ушел пить кофе.
Больше всех доставил сбербанк, который привел с собой команду одинаково-зеленых девушек из HR.
Интересный проект, но, насколько я понимаю, ориентированный на работодателей, а не на соискателей?
Соотношение средних зарплат: PHP 65 311 рублей, в моих кругах даже самые твердолобые зарабатывают больше, процентов на 60%.

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

В моем городе например есть вакансии 40 000-50 000 и я точно знаю они не закрываются годами.

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

  • Нет опыта
  • От 1 года до 3 лет
  • От 3 до 6 лет
  • Более 6 лет
Интересная идея! Технически такое реализовать можно — у API HeadHunter есть поиск по резюме.
Одна проблема, этот поиск доступен не всем:

Поиск резюме доступен только при авторизации работодателем и при условии, что приложение входит в список разрешенных.
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity