Я так понимаю, что Enterprise API это не что иное, как Enterprise Service Bus (ESB) только собственной разработки. Или под капотом что-то общеизвестное от именитого вендора и просто так называют ESB внутри компании?
@morskoi, уверен на 99%, что в Вашем достаточно крупном банке OPS конкретного сервиса и OPS отвечающий за merge в master это совершенно разные люди и могут даже не знать друг друга и не иметь контактов для экстренной связи.
Возникает вопрос: Что делать если ошибка в скриптах была выявлена в момент установки на пром и связана с особенностями этого стенда? OPS конкретного сервиса мог бы её поправить в онлайне за несколько минут, но тут такой ему квест навязали, что уложиться в рамках отведённого времени просто нереально. Может стоит поискать более оптимальный путь? Я не пишу про отмену проверок, я имею ввиду, что скорость изменения кода скриптов в ветке master при таком подходе будет происходить от нескольких часов до нескольких дней, даже если есть контакты OPS-а ответственно за merge.
В идеале, конечно, когда в команде два лида, один по технической части, второй по политической. Очень трудно совмещать, особенно в командах, где количество сотрудников составляет несколько десятков человек.
Набрёл на статью по поиску в гугле. Пишу, скорее, для менеджеров, которые тоже нашли эту статью, чем автору. Нельзя совмещать сопровождение и развитие, это должны быть разные люди. Если вы заставляете инженера сопровождения заниматься внедрением какой-то новой системы или даёте ему поручения не связанные с сопровождением, да ещё и сроки сжатые, как это обычно бывает, то под вашим давлением он забьёт на старые системы и это приведёт к аварийной ситуации. А если он ещё и не проследит за бэкапами и прочей работой, которую не видят менеджеры, закончившие двухнедельные курсы по управлению и не имеющие реального опыта сопровождения, то это это будет полный провал в управлении.
Вы правы, ХЕN используется в версии для x86. Заменил этот абзац.
Цель статьи указана в её заголовке, это небольшая шпаргалка(how-to). На Хабре часто вижу статьи, написанные в таком стиле. Они даже иногда появляются на главной странице, поэтому решил выложить свои заметки. Возможно будет кому-то полезно, возможно нет :)
Оглядываясь в прошлое могу сказать, что лучше бы я в юности уделял больше времени математике и другим точном наукам, а не компьютерам.
Друзья, в новой версии какая-то проблема с OVPN-сервером. В логах пишет "wrong OVPN data". Никто не сталкивался?
Такой бардак возможен только в банке. В крупном банке.
Java Decompiler - меня никогда не подводил. Мне кажется, что им проще работать, чем CFR. Хотя, возможно, что я просто плохо разбираюсь в этой теме.
Список рекомендованный, а не обязательный.
Мне не стыдно признаться в том, что я чего-то не знаю или не понимаю. Я просто хочу разобраться.
Поправьте меня если я не прав.
API Gateway это паттерн, а ESB это уже больше про классификацию ПО реализующего, в том числе, и этот паттерн.
Я так понимаю, что Enterprise API это не что иное, как Enterprise Service Bus (ESB) только собственной разработки. Или под капотом что-то общеизвестное от именитого вендора и просто так называют ESB внутри компании?
Всё это конечно познавательно, но самого скрипта по рутированию нет, ссылка zalil.su/6937580 битая. Какой тогда смысл в этой статье?
@morskoi, уверен на 99%, что в Вашем достаточно крупном банке OPS конкретного сервиса и OPS отвечающий за merge в master это совершенно разные люди и могут даже не знать друг друга и не иметь контактов для экстренной связи.
Возникает вопрос: Что делать если ошибка в скриптах была выявлена в момент установки на пром и связана с особенностями этого стенда? OPS конкретного сервиса мог бы её поправить в онлайне за несколько минут, но тут такой ему квест навязали, что уложиться в рамках отведённого времени просто нереально. Может стоит поискать более оптимальный путь? Я не пишу про отмену проверок, я имею ввиду, что скорость изменения кода скриптов в ветке master при таком подходе будет происходить от нескольких часов до нескольких дней, даже если есть контакты OPS-а ответственно за merge.
Набрёл на статью по поиску в гугле. Пишу, скорее, для менеджеров, которые тоже нашли эту статью, чем автору. Нельзя совмещать сопровождение и развитие, это должны быть разные люди. Если вы заставляете инженера сопровождения заниматься внедрением какой-то новой системы или даёте ему поручения не связанные с сопровождением, да ещё и сроки сжатые, как это обычно бывает, то под вашим давлением он забьёт на старые системы и это приведёт к аварийной ситуации. А если он ещё и не проследит за бэкапами и прочей работой, которую не видят менеджеры, закончившие двухнедельные курсы по управлению и не имеющие реального опыта сопровождения, то это это будет полный провал в управлении.
Цель статьи указана в её заголовке, это небольшая шпаргалка(how-to). На Хабре часто вижу статьи, написанные в таком стиле. Они даже иногда появляются на главной странице, поэтому решил выложить свои заметки. Возможно будет кому-то полезно, возможно нет :)