Эх, жаль, что из заголовка ушло DevOps as a Service - первое, на что я среагировал, поскольку именно эту тему сейчас прорабатываем.
Как по мне, так вполне справедливо употребление этого термина, в первую очередь в связи одним из наиболее частных пунктов во внедрении devops методологии/ принятия devops культуры (как хотите называйте) - ops-инженеры и разработчики становятся частью одной команды. Выделение неких "devops" инженеров в отдельную структуру может и будет воспринято как отхождение от принципов devops и возврат к классической функциональной структуре. И Devops as a service, на мой взгляд, это попытка:
а) решить проблему сегментации тех. опыта и шаринга знаний при невозможности насытить инфраструктуру (читай - каждую команду каждого продукта) необходимым кол-вом инженеров
б) взять лучшие наработки ITSM и подружить их с принципами devops - полностью отвергать предыдущий опыт, на мой взгляд, неправильно
в) показать, как может выглядеть адаптация devops методологии в организациях, на которых переиспользование опыта того же amazon или netflix будет слишком травматичным из-за чего от реализации хоть чего-то из стека devops просто откажутся.
Саш, к тебе пара вопросов:
«В зависимости от наличия или отсутствия проектного офиса, продуктовой фабрики, особенностей процессов компании, служба может работать по разному. Это может быть:
привлечение людей на проекты в виде аллокации;
аллокация на вид работ по какой‑то системе;
использование конкретной работы «под ключ».
Мог бы ты раскрыть этот пункт - как могут выглядеть работы в рамках DaaS. Мне тут видятся следующие основные риски:
Как не скатиться обратно к матричной модели, т.е. выделению инженера на проект на постоянку?
Как быть с maintanence-задачами? Да, мы сделали проект под ключ, набодяжили там мониторинг, обучили людей как с этим работать. Но так или иначе что-то там будет ломаться, что-то потребует постоянного контроля со стороны [dev]ops-инженеров - не все получится отдать разработчикам/тестировщикам с концами. Должно ли это выглядеть как "подписка на сервис" - т.е. от DaaS это будет как постоянная услуга, а все остальное - кто выполняет, как выполняет - под капотом сервиса, как в ITSM?
"И делаете большую презентацию на уровне компании. Почему так широко? Потому что, как правило, данное внедрение осуществляется на уровне компании, а не просто на примере небольшого подразделения, ибо все участники цикла разработки должны начать жить по новому процессу, иначе это работать не будет."
Могут ли все же, пусть с некими ограничениями, и, возможно, с меньшим положительным эффектом, существовать реализации подобного на масштабе подразделения? Сейчас мне видится DaaS как реальная альтернатива матричной структуре в условия ограниченных людских ресурсов (и ограниченных админ.ресурсов, чего уж греха таить).
Удивительное дело: полностью согласен с выводами, к которым пришел автор статьи, но абсолютно не согласен с тем путем, которым он к ним пришел, опровергая необходимость казалась бы фундаментальной best practices о блокировке учетных записей.
Оповещения о событиях неудачного логина и блокировки, как и сама блокировка после n-го количества неудачных входов — обязательное требование многих стандартов ИБ, как наших, так и зарубежных. Интересно, как вы сможете пройти аудит по одному из этих стандартов, если побоялись веерной блокировки учеток и включили эту политику.
Есть множество способов обнаружения таких атак, каждый из которых по сути сводится к мониторингу, в той или иной степени автоматизированному. Но все это в дополнение к политике блокировки учетки после 6 (чаще всего встречал это значение) неудачных попыток входа.
Хотелось бы пожелать Автору и дальше с таким энтузиазмом смотреть на свою работу и не превратиться в админа, который ходит на работу только чтобы запустить танки и иже с ними. Побольше бы таких ИТшников…
Со многим из описанного в статье сталкивался на собственном опыте, хотя и не приходилось пока что работать в бюджетной организации. В частности, пришлось по работать как в организациях, в которых helpdesk только начинали внедрять, так и в организациях, где это уже давно и очень даже неплохо работает.
Есть инициативы, которые могут исходить снизу (от эникейшика/админа), которые не требуют поддержки начальства (лишь бы не мешали и времени хватало). В частности, система мониторинга больше всего нужна прежде всего админам, ее развертывание — интересный и нужный опыт, здесь не нужен пинок сверху. А вот система тикетов/заявок, helpdesk и «прочее такое» — это уже то, что коснется всех сотрудников предприятия, и в этом случае без поддержки начальства (их желания подписывать регламенты, SLA и прочие связанные с локально-нормативные акты) ничего не выйдет.
Где-то на хабре была серия постов об опыте внедрения helpdesk-системы. В подобных проектах, на мой взгляд, очень важно правильно определить, что хочет начальство. В случае с коммерческими организациями это чаще всего деньги (больше прибыль/меньше затраты); в случае с «бюджетными» начальниками, наверное, их стремление подольше оставаться на своем, скорее всего весьма хлебном, месте. И уже исходя из этих потребностей руководства нужно преподносить свой проект (чем бы он ни был) — как он может помочь им — руководителям — достичь их целей. Просто так прийти и рассказывать о всяких красивых теориях, типо ITSM, в большинстве случаев не прокатит. Что организация в целом и руководство в частности получит в случае удачной реализации проекта — вот что для этого самого руководства важно.
> У сони уже лет десять есть ноутбуки в этом сегменте.
> Но ок, пусть толщина: последний Z21 очень тонкий.
Последний Z вышел вовсе не 10 лет назад, а совсем недавно.
> Поговорим об этом, когда хоть одна компания таки разродится конкретным устройством,…
А это здесь причем? Да, мир не совершенен. :) Но я говорю о том, что линейка Z позиционируется в другом ценовом сегменте, нежели samsung из темы. Вот когда samsung представит донелзя напичканый новейшими технологиями ноубук, тогда да, это будет ответ на Sony Z. А пока что это четко сформулированная заявка на сегмент ноутбуков, самый яркий представитель которого Air.
А какие модели есть или были у Sony в этом сегменте? В статье речь идет о «ультрабуках» — т.е. очень тонких, зачастую обделенных интерфейсами ноутбуках с весом не больше 1,5 кг. И с большим временем работы. Какие у сони Sony были или есть модели в этом сегменте? TT? Они намного толще. X? Это вообще очень дорогой нетбук на атоме. Z? Это очень производительные и легкие ноутбуки, со всеми возможными на момент выпуска хардверными технологиями. Но это никак не ультрабуки. Их возможная замена — да. Но все же они толще и зачастую дороже.
У Sony пока нет ноутбука в этом сегменте. Так что это если и «ответ», то скорее Air'у. А если говорить о Сони, то я щас набираю этот текст с прошлогодней модели Z-серии — разрешение экрана ощутимо больше при той же диагонали; тоже ssd, но два по 64 в raid0, чтобы быстрее; да, корпус не такой тонкий, зато вместились все нужные разъемы; dvd-привод; и при всем этом тяжелее на 200 грамм. А цена та же. Так что ИМХО до линейки VAIO Z этот самсунг не дотягивается.
Неплохой обзорчик про хороший внешний хард.
Однако меня слегка выбила из равновесия фраза «О Picasa особо рассказывать нечего, этакий „мини-фотошоп“.» Насколько я знаю, Picasa — программа для организации хранения (каталогизации, если хотите) фотографий на компьютере. Функций редактирования фото там крайне мало. Даже некоторые мыльницы предоставляют больше. Ее можно сравнить с Windows Live Photo Gallery или с ACDSee накрайняк. Может это, конечно, и не важно в контексте данной статьи, просто как то обидно за Photoshop.
Маленькая поправочка: если верить автору, анонс данного ноута состоялся на CeBIT 2009. Эта выставка была в марте, а не летом, как говориться в статье. Это и ввело меня в заблуждение. А вы даете мне ссылку на свежеаннонсированные ноутбуки. Фора почти в полгода! Я думаю, что за это время действительно можно ожидать появление новинок (именно новинок, Qosmio X500 первый ноутбук на новой платформе) с новым процессором.
Я полагаю, что работы над этим ноутбуком шли не месяц и не два. Анонс состоялся только летом. Так что практически нереально ожидать от ASUS, чтобы она перед начала продаж впихнула туда новый процессор. Такие «машинки» тестируются месяцами, каждая деталька подгоняется друг к другу. Ибо цена обязывает.
Согласен. Два БП по 1 кВт на системку с двумя 9800 GT — это как то неправильно. Оно конечно понятно, что апгрейд и все такое, однако я всегда представлял себе уже собранные системники от производителя как нечто цельное, не нуждающее в дополнительной доводке и апгрейде. А тут явный дисбаланс. Раз уж это не топовая комплектация, так зачем пихать туда электричества под завязку
Ну, я бы не сказал, что оригинальных корпусов прямо таки «полно». Они, безусловно, присутствуют на рынке, однако их мало. Еще меньше корпусов, к оформлению которых компания-производитель относится со всей ответственностью (я имею ввиду подбор материалов, качество исполнения, нововведения). С другой стороны, я полностью согласен с тем, что мало кому нужны по настоящему хорошие (во всех смыслах), дизайнерские корпуса. Спрос рождает предложение. Все закономерно.
Просто я хотел отметить то, насколько серьезно Asus подошла к это составляющей своего творения. Браво!
Действительно брутальная машинка. Сегодня редко можно встретить такое внимание к дизайну корпуса. В основном производители лепят стандартные коробки. А тут видно, постарались дизайнеры.
Information
Rating
Does not participate
Location
Сургут, Тюменская обл. и Ханты-Мансийский АО, Россия
Эх, жаль, что из заголовка ушло DevOps as a Service - первое, на что я среагировал, поскольку именно эту тему сейчас прорабатываем.
Как по мне, так вполне справедливо употребление этого термина, в первую очередь в связи одним из наиболее частных пунктов во внедрении devops методологии/ принятия devops культуры (как хотите называйте) - ops-инженеры и разработчики становятся частью одной команды. Выделение неких "devops" инженеров в отдельную структуру может и будет воспринято как отхождение от принципов devops и возврат к классической функциональной структуре. И Devops as a service, на мой взгляд, это попытка:
а) решить проблему сегментации тех. опыта и шаринга знаний при невозможности насытить инфраструктуру (читай - каждую команду каждого продукта) необходимым кол-вом инженеров
б) взять лучшие наработки ITSM и подружить их с принципами devops - полностью отвергать предыдущий опыт, на мой взгляд, неправильно
в) показать, как может выглядеть адаптация devops методологии в организациях, на которых переиспользование опыта того же amazon или netflix будет слишком травматичным из-за чего от реализации хоть чего-то из стека devops просто откажутся.
Саш, к тебе пара вопросов:
«В зависимости от наличия или отсутствия проектного офиса, продуктовой фабрики, особенностей процессов компании, служба может работать по разному. Это может быть:
привлечение людей на проекты в виде аллокации;
аллокация на вид работ по какой‑то системе;
использование конкретной работы «под ключ».
Мог бы ты раскрыть этот пункт - как могут выглядеть работы в рамках DaaS. Мне тут видятся следующие основные риски:
Как не скатиться обратно к матричной модели, т.е. выделению инженера на проект на постоянку?
Как быть с maintanence-задачами? Да, мы сделали проект под ключ, набодяжили там мониторинг, обучили людей как с этим работать. Но так или иначе что-то там будет ломаться, что-то потребует постоянного контроля со стороны [dev]ops-инженеров - не все получится отдать разработчикам/тестировщикам с концами. Должно ли это выглядеть как "подписка на сервис" - т.е. от DaaS это будет как постоянная услуга, а все остальное - кто выполняет, как выполняет - под капотом сервиса, как в ITSM?
"И делаете большую презентацию на уровне компании. Почему так широко? Потому что, как правило, данное внедрение осуществляется на уровне компании, а не просто на примере небольшого подразделения, ибо все участники цикла разработки должны начать жить по новому процессу, иначе это работать не будет."
Могут ли все же, пусть с некими ограничениями, и, возможно, с меньшим положительным эффектом, существовать реализации подобного на масштабе подразделения? Сейчас мне видится DaaS как реальная альтернатива матричной структуре в условия ограниченных людских ресурсов (и ограниченных админ.ресурсов, чего уж греха таить).
Оповещения о событиях неудачного логина и блокировки, как и сама блокировка после n-го количества неудачных входов — обязательное требование многих стандартов ИБ, как наших, так и зарубежных. Интересно, как вы сможете пройти аудит по одному из этих стандартов, если побоялись веерной блокировки учеток и включили эту политику.
Есть множество способов обнаружения таких атак, каждый из которых по сути сводится к мониторингу, в той или иной степени автоматизированному. Но все это в дополнение к политике блокировки учетки после 6 (чаще всего встречал это значение) неудачных попыток входа.
Со многим из описанного в статье сталкивался на собственном опыте, хотя и не приходилось пока что работать в бюджетной организации. В частности, пришлось по работать как в организациях, в которых helpdesk только начинали внедрять, так и в организациях, где это уже давно и очень даже неплохо работает.
Есть инициативы, которые могут исходить снизу (от эникейшика/админа), которые не требуют поддержки начальства (лишь бы не мешали и времени хватало). В частности, система мониторинга больше всего нужна прежде всего админам, ее развертывание — интересный и нужный опыт, здесь не нужен пинок сверху. А вот система тикетов/заявок, helpdesk и «прочее такое» — это уже то, что коснется всех сотрудников предприятия, и в этом случае без поддержки начальства (их желания подписывать регламенты, SLA и прочие связанные с локально-нормативные акты) ничего не выйдет.
Где-то на хабре была серия постов об опыте внедрения helpdesk-системы. В подобных проектах, на мой взгляд, очень важно правильно определить, что хочет начальство. В случае с коммерческими организациями это чаще всего деньги (больше прибыль/меньше затраты); в случае с «бюджетными» начальниками, наверное, их стремление подольше оставаться на своем, скорее всего весьма хлебном, месте. И уже исходя из этих потребностей руководства нужно преподносить свой проект (чем бы он ни был) — как он может помочь им — руководителям — достичь их целей. Просто так прийти и рассказывать о всяких красивых теориях, типо ITSM, в большинстве случаев не прокатит. Что организация в целом и руководство в частности получит в случае удачной реализации проекта — вот что для этого самого руководства важно.
> Но ок, пусть толщина: последний Z21 очень тонкий.
Последний Z вышел вовсе не 10 лет назад, а совсем недавно.
> Поговорим об этом, когда хоть одна компания таки разродится конкретным устройством,…
А это здесь причем? Да, мир не совершенен. :) Но я говорю о том, что линейка Z позиционируется в другом ценовом сегменте, нежели samsung из темы. Вот когда samsung представит донелзя напичканый новейшими технологиями ноубук, тогда да, это будет ответ на Sony Z. А пока что это четко сформулированная заявка на сегмент ноутбуков, самый яркий представитель которого Air.
А какие модели есть или были у Sony в этом сегменте? В статье речь идет о «ультрабуках» — т.е. очень тонких, зачастую обделенных интерфейсами ноутбуках с весом не больше 1,5 кг. И с большим временем работы. Какие у сони Sony были или есть модели в этом сегменте? TT? Они намного толще. X? Это вообще очень дорогой нетбук на атоме. Z? Это очень производительные и легкие ноутбуки, со всеми возможными на момент выпуска хардверными технологиями. Но это никак не ультрабуки. Их возможная замена — да. Но все же они толще и зачастую дороже.
Мы зрим в корень проблемы/вопроса.
Однако меня слегка выбила из равновесия фраза «О Picasa особо рассказывать нечего, этакий „мини-фотошоп“.» Насколько я знаю, Picasa — программа для организации хранения (каталогизации, если хотите) фотографий на компьютере. Функций редактирования фото там крайне мало. Даже некоторые мыльницы предоставляют больше. Ее можно сравнить с Windows Live Photo Gallery или с ACDSee накрайняк. Может это, конечно, и не важно в контексте данной статьи, просто как то обидно за Photoshop.
Просто я хотел отметить то, насколько серьезно Asus подошла к это составляющей своего творения. Браво!