Легко на простейших вещах и примерах разносить в пух и прах примеры, которые сокращены просто для понимания.
А если взять не классы фигур с простейшими операциями, а серьезные блоки кода со своей очень разной логикой, то эти свичи вдруг становятся неимоверно геморным вариантом. А добавление нового модуля вырастает в лотерейку "сломается/не сломается", тогда как добавление нового модуля и его присоединение тривиальная и надёжная процедура.
Не нужно впадать в крайности и преподносить специально упрощённые примеры для разгрома - выглядит так себе.
А я где-то высказал претензии к качеству? =)))
Я четко очертил свою позицию, что мне не по душе, когда за предоставляемую услугу исполнитель четко информирует, что не несет ответственности. Это мне немного напоминает консервный шкафчик в магазине — вещи вроде бы и под замком, но если что — администрация не несет ответственности за сохранность.
Для задач, нетребовательных к стабильности и скорости работы — отличный вариант, почему нет… Но я психую, если что-то из моих сервисов начинает тормозить или глючить по не зависящим от меня обстоятельствам, потому предпочитаю чуть больше заплатить, но получить более качественное обслуживание.
Знаете, заинтересовали, если бы не одно НО — один из пунктиков ограничений, что нет никаких гарантий по стабильности и качеству работы таких VDS.
Промо, конечно, это круто и цена вообще шикарная, но любая услуга должна быть качественной, и Вы лишний раз подтвердили истину «быстро, дешево, качественно — выбирай любые два пункта», и к сожалению, из двух оставшихся вариантов (т.к. дешево занято 30 рублями), выбрали не качество, а скорость (хотя и непонятно, скорость ЧЕГО) =((
Кстати, в перечислениях сбоев работы IPMI указано, что все причины как бы «влияют в целом на работу железа». Это не совсем так — есть один баг/фича, который может вывести из работы IPMI, по сути не являясь неисправностью. Сам столкнулся с такой проблемой не так давно.
При подключении сервера необходимо сначала на полностью обесточенном оборудовании подключить порт IPMI/Ethernet (смотря как настроено), и только потом подавать питание.
И как следствие этой фичи, если при включенном сервере отключить даже кратковременно сетевой кабель, то IPMI вырубается и даже физическая перезагрузка сервера не возвращает ее в нормальное состояние. Приходится гасить сервер целиком, выдергивать питание, потом снова подавать его — и только тогда восстанавливается его работа.
Сейчас, возможно, все нормализовалось, но на более старых версиях платы проблема имеет место быть.
Вы реально не понимаете, что devops — это больше техническая должность, а не менеджерская?
А Вы реально читаете только то, что хотите? Напоминаю…
По мне, так девопс нужен, только должен быть не просто «натасканный системщик», а скорее архитектор со знанием инструментария аналитики и работы программиста (уметь кодить хотя бы на уровне немного выше среднего)…
оу-оу-оу… не ожидал такого напора от содружества =))) попробую изложить свое видение этой единицы процесса и причины… (эти выводы у меня сложились непосредствено на личном опыте работы в команде без/с девопс-ом — и негативные и позитивные)…
1. да, именно админ/менеджер — т.к. он как раз в первую очередь обладает умением коммуникации и умением разобраться и настроить, и не надо путать с «менеджером-продажником» (задача которого убедить, что мы такие клевые)
2. навыки программирования ему как раз и нужны для того, чтобы он знал и умел настроить автоматизированные системы деплоя, тестирования подключить нужные библиотеки и т.д.
3. навыки тестирования нужны, чтобы вместо отвлекания девелоперов на исправление какой-то мелочи в тестах, мог это сделать сам, особенно сли речь идет именно об изменении параметров конкретного теста
4. да, именно конкретный человек должен отвечать за попадание продукта в продакшн, а не девелоперы, которых может быть десяток-два-пять… девопс получил результаты тестов, принял решение устраивает ли продукт, выполнил деплой на прод или отправил на исправления, а не девелопер Вася, получив по своей части «добро» прощелкал, что зацепил нечаяно кусок работы девелопера Гены…
Да, такой человек будет стоить реально денег, может я частично даже его путаю с СЕО проекта, но имхо — это правильнее, и когда мы начали работать именно так, результаты стали существенно лучше (хотя наш девопс начинал именно с позиции просто админ, а в процессе уже обучался и часть функций взял на себя, а мы ему поначалу помогали кто чем мог)…
Ну скажем так, лично я не следую всем методологиям и критериям «буква в букву» ;)
ИМХО — понятие ДевОпс-а нужно, но только в таком виде, в котором не подразумевается размытости должностных обязанностей и ответственности, и уж тем более перераспределение функций, которые на людей, которые НЕ ДОЛЖНЫ ими заниматься…
Проект = архитектор/проектировщик, код = программисты, тест = тестировщики, деплой = менеджер/администратор, взаимодействие с юзерами = саппорт…
Ну или я допускаю, что не совсем понимаю именно методологии =)
Либо Вы ошиблись ссылкой «ответить», либо плохо читаете… Вообще-то я не против такой сущности как ДевОпс, но этот человек должен обладать набором знаний, а не быть простым системщиком или менеджером, как это ооочень часто происходит.
Программист не должен заморачиваться вообще процессами сборки продакшна, передачей его на тестирование или самим тестингом и уж тем более деплоем на рабочие площадки.
Так что не совсем понятно, почему Вы МНЕ адресовали Ваше сообщение =)
А чем измерять толк? Количеством строк кода? Тестеры нужны, причем два уровня:
— те, кто знают, как должно работать и проверяют соответствие реализации поставленной задаче, поиску технических несоответствий
— те, кто ничего не знают, а выполняют роль простых юзеров, и пытаются убить/сломать/испортить реализацию, как «обезьяны с гранатами»
По мне, так девопс нужен, только должен быть не просто «натасканный системщик», а скорее архитектор со знанием инструментария аналитики и работы программиста (уметь кодить хотя бы на уровне немного выше среднего)… В противном случае — это тот же самый менеджер продукта, которому понавешали обязанностей, которые он не знает как выполнять, потому выполняет «как умеет», пока не научится выполнять «хоть немного»…
А если кому то код нужно будет немного изменить под свои цели, то это исключительно его геморой (проблемы индейцев шерифа не колышат).
Легко на простейших вещах и примерах разносить в пух и прах примеры, которые сокращены просто для понимания.
А если взять не классы фигур с простейшими операциями, а серьезные блоки кода со своей очень разной логикой, то эти свичи вдруг становятся неимоверно геморным вариантом. А добавление нового модуля вырастает в лотерейку "сломается/не сломается", тогда как добавление нового модуля и его присоединение тривиальная и надёжная процедура.
Не нужно впадать в крайности и преподносить специально упрощённые примеры для разгрома - выглядит так себе.
Я четко очертил свою позицию, что мне не по душе, когда за предоставляемую услугу исполнитель четко информирует, что не несет ответственности. Это мне немного напоминает консервный шкафчик в магазине — вещи вроде бы и под замком, но если что — администрация не несет ответственности за сохранность.
Для задач, нетребовательных к стабильности и скорости работы — отличный вариант, почему нет… Но я психую, если что-то из моих сервисов начинает тормозить или глючить по не зависящим от меня обстоятельствам, потому предпочитаю чуть больше заплатить, но получить более качественное обслуживание.
Промо, конечно, это круто и цена вообще шикарная, но любая услуга должна быть качественной, и Вы лишний раз подтвердили истину «быстро, дешево, качественно — выбирай любые два пункта», и к сожалению, из двух оставшихся вариантов (т.к. дешево занято 30 рублями), выбрали не качество, а скорость (хотя и непонятно, скорость ЧЕГО) =((
Или это касается только более поздних версий прошивки?
При подключении сервера необходимо сначала на полностью обесточенном оборудовании подключить порт IPMI/Ethernet (смотря как настроено), и только потом подавать питание.
И как следствие этой фичи, если при включенном сервере отключить даже кратковременно сетевой кабель, то IPMI вырубается и даже физическая перезагрузка сервера не возвращает ее в нормальное состояние. Приходится гасить сервер целиком, выдергивать питание, потом снова подавать его — и только тогда восстанавливается его работа.
Сейчас, возможно, все нормализовалось, но на более старых версиях платы проблема имеет место быть.
А Вы реально читаете только то, что хотите? Напоминаю…
1. да, именно админ/менеджер — т.к. он как раз в первую очередь обладает умением коммуникации и умением разобраться и настроить, и не надо путать с «менеджером-продажником» (задача которого убедить, что мы такие клевые)
2. навыки программирования ему как раз и нужны для того, чтобы он знал и умел настроить автоматизированные системы деплоя, тестирования подключить нужные библиотеки и т.д.
3. навыки тестирования нужны, чтобы вместо отвлекания девелоперов на исправление какой-то мелочи в тестах, мог это сделать сам, особенно сли речь идет именно об изменении параметров конкретного теста
4. да, именно конкретный человек должен отвечать за попадание продукта в продакшн, а не девелоперы, которых может быть десяток-два-пять… девопс получил результаты тестов, принял решение устраивает ли продукт, выполнил деплой на прод или отправил на исправления, а не девелопер Вася, получив по своей части «добро» прощелкал, что зацепил нечаяно кусок работы девелопера Гены…
Да, такой человек будет стоить реально денег, может я частично даже его путаю с СЕО проекта, но имхо — это правильнее, и когда мы начали работать именно так, результаты стали существенно лучше (хотя наш девопс начинал именно с позиции просто админ, а в процессе уже обучался и часть функций взял на себя, а мы ему поначалу помогали кто чем мог)…
ИМХО — понятие ДевОпс-а нужно, но только в таком виде, в котором не подразумевается размытости должностных обязанностей и ответственности, и уж тем более перераспределение функций, которые на людей, которые НЕ ДОЛЖНЫ ими заниматься…
Проект = архитектор/проектировщик, код = программисты, тест = тестировщики, деплой = менеджер/администратор, взаимодействие с юзерами = саппорт…
Ну или я допускаю, что не совсем понимаю именно методологии =)
Программист не должен заморачиваться вообще процессами сборки продакшна, передачей его на тестирование или самим тестингом и уж тем более деплоем на рабочие площадки.
Так что не совсем понятно, почему Вы МНЕ адресовали Ваше сообщение =)
— те, кто знают, как должно работать и проверяют соответствие реализации поставленной задаче, поиску технических несоответствий
— те, кто ничего не знают, а выполняют роль простых юзеров, и пытаются убить/сломать/испортить реализацию, как «обезьяны с гранатами»