Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a пылаева дана, шоколад лего-скрам
Semelhante a пылаева дана, шоколад лего-скрам (20)
Mais de Magneta AI
Mais de Magneta AI (20)
пылаева дана, шоколад лего-скрам
- 1. Шоколад, LEGO и Scrum – Знакомство с DevOps Дана Пылаева Rakuten Marketing
- 3. Agile Coach Scrum Master, CSM, CSP Программист @DanaPylayeva DBA Менеджер Системный Ахитектор Докладчик Куратор Организатор конференции …Bсякое Бывало
- 4. Rakuten Marketing – global leader in Omni-channel marketing
- 5. Rakuten Inc.
- 6. DevOps: Растущая Популярность http://www.google.ru/trends/explore#q=devops&date=1%2F2009%2073m&cmpt=geo&tz= 2009 2013 DevOps Дефлопе Meetup "DevOps Moscow in Russian” “10 + deploys per day” Velocity Conference
- 7. DevOps. C Чем Его Едят?? ©PhotobyRomanBarshay
- 8. DevOps: Это Что Или Kто? “Разработчик у которого есть root access” “Bолшебный человек, который может поднять упавший сервер, починить баг, из-за которого он упал и установить новую версию приложения” “СисАдмин, который пытается автоматизировать все что только можно” Подслушано на форумах...
- 9. “Mетодология в разработке ПО, нацеленная на общение, взаимодействие и интеграцию специалистов по разработке ПО и специалистов в информационных технологиях” https://ru.wikipedia.org/wiki/DevOps DevOps
- 10. Столпы DevOps Culture Культура Automation Автоматизация Lean Бережливое производство Measurement Измерение Sharing Обмен Знаниями
- 12. Три Источника, Одна Идея Ускорение обратной связи
- 13. Обратная Связь и Scrum потенциально готовый к поставке продукт
- 14. …Обратная Связь С Задержкой потенциально готовый продукт
- 16. Классический Конфликт Интересов Сисадмин Отвечающий за стабильность системы Клиент постоянно меняющий требования. Разработчик спешащий внести новые изменения в ПО.
- 17. Cюжетно-ролевая игра: Шоколад, LEGO и Scrum.
- 18. ChocolateLegoScrum.com Группа Системных Администрато ров Scrum- команда разработчиков Scrum- команда разработчиков Scrum- команда разработчиков Бизнес группа Клиенты Обратная связь, рыночный спрос История ( User Story) История ( User Story) История ( User Story) Вымышленная Kомпания, Выпускающая ПО
- 19. Шоколад, LEGO и Scrum: Роли Команда Scrum Группа ИТ Сергей Scrum Master Рома Разработчик (4) Толик Тестировщик (2) Влада Владелец Продукта Слава СисАдмин Руслан Релиз Белла Безопасность И Другие: Клиент Кириллов Бизнес Борисов Harry Hacker
- 20. Переход к ДевОпс за 3 Спринта Спринт 1 - вжиться в существующий процесс. Спринт 2 - оптимизация команды. Спринт 3 - оптимизация всей системы "от-разработки-до-эксплуатации“. Шоколад, LEGO и Scrum
- 21. Цель игроков - Максимизировать прибыль.
- 22. Что Же Мы Выпускаем? История (User Story) Пакет развертывания Внутри - 5 индивидуальных пакетов с Лего-кошкой и шоколадом. Лего-животное - это функционал нашего ПО. Шоколад - это документация.
- 23. Разработчики и группа ИТ особо не общаются. Тестирование безопасности - в конце разработки. "Потенциально готовый продукт" в конце Спринта. Число релизов ограничено. Спринт 1. Новые команды Scrum
- 24. Что ваша команда сделает по-другому в Спринт 2?
- 25. Тестирование Безопасности и Первое Развертывание Разработчики и группа ИТ особо не общаются Тестирование безопасности в процессе разработки. Развертывание на «боевых» серверах делает только Релиз- Инженер Спринт 2.
- 27. Все Гораздо Cерьезней "Скорость изменения бизнес-требований, бесспорно, растет пугающим темпом для тех организаций, которые не в состоянии поспеть за ней.“ The Seven Habits Of Highly Effective DevOps by Glenn O’Donnell and Kurt Bittner, Forrester Research, Inc, September 3, 2013
- 28. Частота Развертываний Обновлений ПО в Amazon 11.6 секунд
- 29. “Перемен требуют наши сердца.” ~Цой
- 30. "Вы можете не меняться. Выживание – дело добровольное" (Деминг)
- 31. С Чего Же Начать?
- 32. Шаг 1. Найти ограничения системы(bottleneck) Шаг 2. Решить, как эффективно эксплуатировать ограничения системы. Шаг 3. Согласовать все остальные действия с этим решением. Шаг 4. Повысить пропускную способность ограничения. Шаг 5. Внимание!!! Если на предыдущем этапе узкое звено было устранено, то перейти к шагу 1, но не позволяйте инерции создавать новые ограничения. Теория Ограничений (TOC)
- 33. The flow-of-time Clock, Bernard Gitton . Europa Center, Berlin Цель: Oптимизация Eдиного Потока Pаботы Bнутри Oрганизации
- 34. The flow-of-time Clock, Bernard Gitton . Europa Center, Berlin А Kаков Поток Pаботы Bнутри Bашей Kомпании?
- 35. Карта потока создания ценности
- 36. #1: Начнем с поиска ограничения (“узкого места“) в системе “от-разработки-до-эксплуатации”.
- 37. Устаревшие инструменты Человеческий фактор Неэффeктивные процессы Системные Oграничения (Bottlenecks) Бывают Pазные:
- 38. Следи за собой! У з к а я С п е ц и а л и з а ц и я Широкие Навыки Continuous Learning = Век Живи, Век Учись!
- 39. #2. Расширим состав Scrum команд, пригласив в них сисадминов.
- 42. #3. Автоматизируем задачи выполняемые вручную: конфигурацию, развертывание, откат...
- 43. Небольшие, Автоматизированные и Регулярные Развертывания. Цель – Continuous Deployment
- 44. Source: "The forgotten half of change“, L. de Brabandere Время Время DevOps - Измениться Дважды.
- 45. Спринт 3. Переходим на DevOps Pасширение навыков Быстрая реакция на проблемы с безопасностью Оптимизация потока (единичные партии) Непрерывное развертывание!
- 46. Вопросы? Возражения? Идеи как улучшить игру? Ретроспектива "В Аквариуме"
- 47. Ну а если память плохая? Что запомнить? ©PhotobyRomanBarshay
- 48. Вы “уже DevOps” если У вас создан и продолжает оптимизироваться непрерывный поток работы в организации. Вы стремитесь к ускорению обратной связи. Ваши разработчики и сисадмины работают над автоматизацией задач, выполняемых вручную. Эксперименты, принятие риска и наработка мастерства стали частью вашей культуры.
- 49. Если еще не читали – прочтите! http://www.labirint.ru/books/472801/
- 50. Что еще почитать? 1. Элияху Голдратт, Джефф Кокс “Цель. Процесс непрерывного совершенствования” 2. Michael Hüttermann “DevOps for Developers” 3. John Allspaw; Jesse Robbins “Web Operations” 4. Donald G. Reinertsen “The Principles of Product Development Flow: Second Generation Lean Product Development” 5. Kenneth S. Rubin “Essential Scrum: A Practical Guide to the Most Popular Agile Process” 6. http://itrevolution.com/the-history-of-devops/ 7. https://www.getchef.com/blog/2010/07/16/what-devops-means-to-me/ 8. http://business.kaspersky.ru/heartbleed-doomsday/1619/ 9. http://xkcd.com/1354/ 10. https://ru.wikipedia.org/wiki/Уязвимость_(компьютерная_безопасность)
- 51. Вы получаете бейдж !
Notas do Editor
- Здравствуйте! Меня зовут Дана, я работаю в компании Ракутeн Маркетинг. Mне очень приятно быть сегодня здесь, и очень приятно видеть так много людей которых интересует тема ДевОпс. Для начала давайте определимся кто есть кто: Кто из вас активно применяет практики ДевОпс в ваших компаниях? А кто слышал про ДевОпс но не совсем уверен что это такое и с чего начать? А кто просто зашел поиграть с Лего и шоколад поесть? Ну чтож, я уверена что в этом мастер-классе найдется что-то для каждого из вас. О ДевОпс можно говорить долго и нудно. Вот как раз этого-то мы c вами и попытаемся избежать. В ближайшие 1.5 часа мы с вами разберемся какую проблему решает ДевОпс, с чего стоит начать переход на ДевОпс и почему вашей компании нужно начинать уже сейчас. Мы будем использовать элементы игрофикации, Лего, Шоколад. Почему Лего и шоколад? Потому что они помогут нам визуализировать те реальные проблемы с которыми сталкиваются современные компании в процессе разработки ПО. А так же по-экспериментировать с вариантами их решения. Возражений нет? Тогда начнем!
- Коротко о себе, я родилась на Донбасе, училась в Москве, живу и работаю в Нью Йорке и я очень рада что оказалась сегодня снова в Москве на этой потрясающей конференции- AgileDays 2015!
- В ИТ я работаю 16 лет, за это время успела перепробовать себя в различных ролях - как на стадии разработки проeктов, так и на стадии их внедрения и поддержки. С Ажайлом столкнулась 10 лет назад, попробовала, понравилось и с тех пор я помогаю другим понять преимущество такого подхода, много работаю с распределенными командами, участвую в проведении и организации конференций.
- Компания в которой я работаю сейчас, занимается цифровым маркетингом. Мы являемся дочерней компанией Ракутена. Те из вас кто слышал о Ракутене, знают его или как японскую товарную площадку, или как бейсбольную команду - Ракутен Иглс.
- На самом деле, Ракутен имеет отделения по всему миру, в разных отраслях: от цифрового маркетинга, до производства телефонов и электронных книжек.
- Но вернемся к ДевОпс. Интерес к налаживанию совместной работы разработчиков и системных администраторов появился относительно недавно. Родоначальником ДевОпс считается бельгиец Paul Dubois. 2007 Классической презентацией привлекшей внимание к первым шагам в этой области является "10 развертываний в день", представленная John Allspaw и Paul Hammond в 2009 на Velocity conference. За рубежом, термин ДевОпс вошел в оборот в 2009 году и на сегодняшний день практики ДевОпс применяются практически во всех ведущих технических компаниях. Скачком популярности в России ДевОпс обязано энтузиазму Александра Титова, Никиты Борзых и Ивана Ефтуховича. В 2013 году эти ребята организовали митап "DevOps-Moscow-in-Russian” и подкаст DevOps Дефлопе.
- Интересно что несмотря на популярность термина ДевОпс, каждый интерпретирует его по-своему. Множество различных определений и трактовок. В плоть до того, что даже аналисты Гартнера в своем докладе "Семь шагов необходимых для начала вашей ДевОпс инициативы ", рекомендуют как шаг номер 1 - "Определитесь что ДевОпс означает для вас«. http://www.osp.ru/os/2014/03/13040804/
- Иногда даже появляется такое мнение, что ДевОпс это не "Что" а "Кто“ Очень распространенное заблуждение что ДевОпс - это роль, новая профессия. Несколько подслушанных мною интересных рассуждений на российских форумах:
- И классическое определение с Википедии..
- John Willis, один ис корифеев ДевОпс, использует аббревиатуру CALMS для его определения (culture, automation, lean, measurement and sharing). Очень легко запомнить: есть такие таблетки которые помогают избавится от бессоницы и нервного напряжения. ДевОпс действует точно также, но на уровне организации.
- С девопс связано множество инструментов позволяющих автоматизировать создание среды, конфигурацию, развертывание и Мониторинг. Однако именно культивирование взаимоотношений между разработчиками И системными аминистраторами является залогом успеха вашей ДевОпс инициативы.
- Одна из самых лучших книг написаных про ДевОпс – “Проект Фених”. Кто из вас читал ее? А кто знает что буквально пару недель назад она появилась в русском переводе? Iнтереснo, что одна из ключевых идей высказанных v Проекте Фених так же отмечается в книге Доналда Рейнертсена “Принципы потока в разработке ПО”. На этой же идее основываются и принципы игрофикации. Кто-нибудь догадался о какой идее идет речь? Конечно же, разговор идет об обратной связи. А именно, о том что ускорение ее, помогает углублению и расширению нашего понимания. Быстрая обратная связь (feedback) помогает нам сорентироваться и скорректировать наши действия в условиях полной непредсказуемости присущей разработке ПО. Конечно же идея обратной связи не нова. В частности, она широко используется в Скраме. Кто из вас знаком со Скрамом?
- Знакомая картинка? Классический Скрам. И нас есть Product Backlog за который отвечает Владелец Продукта. Команда планирует спринт, работает над ним, через 2 – 4 недели производит “потенциально готовый к поставке продукт” и получает обратную связь. Да? Не совсем. Дело в том, что вот это самое “потенциально готовый” вносит неопределенность с точки зрения получения обратной связи.
- Что по-вашему происходит с кодом, который не выпускается в промышленную среду в конце Спринта? - Можем ли мы реально получить от наших клиентов feedback о его работе? Что если конкурирующая компания выпустит крутую фичу, которая у нас написана но все еще дожидается развертывания? Компания может дорого заплатить за эту задержку. Cost of Delay Проблема с этой картинкой в том, что Скрам традиционно используется как фреймворк для разработки ПО. Любая оптимизация процесса, за которую команда берется после ретроспективы, направлена на повышение эффективности команды разработчиков и как правило, не имеет эффекта на ускорении потока работы в организации. Т.е создается иллюзия оптимизации.
- Вот эта самая иллюзия и приводит к тому, что в проэте Феникс описывается как "перекидывание свиньи через стену" - Скрам команда довольна собой и своей скоростью, burndown chart выглядит замечательно А в это время Пакеты развертывания накапливаются и требуют героических усилий СисАдминов во время развертывания релиза, да и после него. В конечном итоге из-за проблем со стабильностью системы и задержками внедрения, страдает кто? Клиенты!
- Вот и получается, что интересы СисАдмина, Разработчика и Клиента не совпадают: Клиент сам незнает чего хочет, но хочет чтоб все было сделано быстро. Разработчик отвечат за быструю разработку ПO. СисАдмин, отвечает за стабильность системы. Ведь каждое изменение потенциально может негативно сказаться на стабильности! В компаниях, где развертывание по-прежнему делатся вручную и редко, этот конфликт интересов неизбежен Что же делать? Давайте экспериментировать!
- О чем эта игра? Об одной вымышленной компании которая преходит к ДевОпс и что из этого получается. Для начала я попрошу вас разделиться на группы. Одна группа в центре - 9 человек одна группа на передовой, возле флипчарта - 8 человек и 3 группы на заднем плане. В каждой по 8 человек. Хватило людей? Отлично!
- Теперь представьте что вы все работаете в вымышленной компании “ChocolateLegoScrum.com” Компания разрабатывает ПО. В нашей интерпретации - животных из Лего. Компания состоит из 3 Скрам команд, одной группы ИТ (наши СисАдмины, Инженеры Безопасности и Релиз Инженеры) и конечно же бизнес. Бизнес группа работает с клиентами, определяя какие животные требуются на рынке И сколько клиенты готовы за них платить. Бизнес выдает (заказы) владельцам продукта, которые в свою очередь работают с командой Скрам чтобы эти продукты произвести. Группа системных администраторов отвечает за стабильность, безопасность и развертывание.
- У каждой команды на столе есть ролевые карты с описанием того, что каждый игрок может делать, а для чего ему понадобится помощь других Например: Разработчик и тестировщик не могут начать работать, пока СисАдмин не создал каждому из них среду разработки и тестирования Разработчик может строить животных из Лего (и документацию), но не можеть делать развертку на проде - для этого он должен передавать работу релиз инженеру.
- Мы разыграем с вами переход к ДевОпс за Три Спринта. По ходу игры правила будут исложняться, будут И сюрпризы. В конце каждого Спринта - ретроспектива. Команда решает, что нужно изменить в след. раз. .
- Перед вами образец пакета развертывания. Что внутри: карточка с user story, маленькие пакеты с животным и шоколадом. На каждом маленькoм пакетe- наклейка с номером. Колличество пакетов соответствует колличеству животных указаному в истории. Ну что понятно для начала? Возьмите пожалуйста карточки, выберите свою роль и пока я буду раздавать игровой материал, oзнакомьтесь co своими возможностями.
- И так наш первый Спринт: Заказы от клиентов получены, Владельцы продуктов встречаются с Бизнесом, узнают рыночный спрос. В следующие 15 минут команды должны доставить клиентам как можно больше продуктов. Кто у нас Scrum мастер? Помните вашу роль. Следите за временем. 2 минуты на планирование Спринта 8 минут на спринт 2 минуты - Демо для Владельца продукта 3 минуты ретроспектива. Таймер будет подавать сигнал в конце каждого интервала и более громкий - в конце всего спринта. После этого каждая команда расскажет нам о том, как они решили улучшить процесс Вопросы? Каждый знает что он делает? Тогда поехали!
- Назовите одно изменение от каждой команды
- Изменение в правилах: - Белла Безопасность может работать с командой Scrum с самого начала - И Тестировщик и Разработчик могут помогать друг другу - В Конце Спринта - первoе Развертывание в промышленной среде.
- Первый удачный релиз это хорошое время остановиться и задуматься , что же произошло. Сработали ваши изменения? Как насчет тестирования на безопасность? Как быстро команда смогла вернуться к работе после аттаки Хакера? Слово группе ИТ - Слава СисАдмин - вам пришлось много поработать, да? Руслан Релиз - ваши впечатления? Как поживают наши клиенты? Спрос на рынке изменился во время второго Спринта, в результате часть продуктов упала в цене. Успела ли команда среагировать на изменение спроса или продолжала работать как ни вчем небывало? Как мы с вами видим, все работали много и тяжело, а клиенты все равно не довольны. Может это только вам попались такие капризные клиенты? Или проблема в том что мы выпускаем продукт слишком редко?
- По словам аналистов из Forrester Research все гораздо серьезней
- Кто-нибудь знает что означает это число? 11.6 секунд –это частота развертываний обновлений ПО в Амазоне. Помните ту презентацию в 2009 году - 10 развертываний в день в компании Flickr - это было что-то невероятное. А теперь Амазон делает это каждые 11.6 секунд! Подумайте о тех компаниях, которые все еще делают развертывания после нескольких спринтов. Или даже после каждые 2 недели в конце спринта! Если бы вы были клиентом, какую компанию выбрали бы вы?
- Что-то должно измениться.
- Компании должны измениться, если конечно они заботятся о своей конкурентноспособности.
- С чего же начать, как узнать какое изменение будет наиболее эффективным? Еще одна хорошая книжка которую стоит почитать. Голдрат обясняет в ней что k оптимизации нужно подходить системно, применяя теорию ограничений.
- Теория ограничений говорит о том, что любые улучшения процесса которые осуществляются до или после ограничения, не влияют на общую производительность системы. И мы с вами можем это подтвердить - ведь самым большим ограничением в нашей системе была частота развертывания. Mы с вами пытались оптимизировать работу Скрам команды, a на скорости доставки продукта клиентам это никак не отразилось!
- Или как говорится в Проекте Феникс: "Наша цель: Обеспечить быстрый, предсказуемый и непрерывный поток работы которая представляет ценность для бизнеса при минимизации воздействия и задержек связанных с незапланированной работой"
- А вы задумывались как выглядит поток работы в вашей компании? Где происходят задержки? Один из способов визуализации - это Value stream mapping Очень интересное упражнение которое помогает в том числе выявить ограничения в системе.
- И так, начнем с поиска "узкого места" или ограничения в цикле "от-разработки-до-эксплуатации”. Вспомним наши Спринт 1 и Спринт 2. Что было ключевым ограничением в нашей с вами компании?
- Обратите внимание, что ограничения в системе могут происходить как из-за применения устаревших инструментов и процессов , так и из-за узкой специализации людей, их устаревшего менталитета и нежелания ничего менять Tool: The way existing tools are used and/or lack of appropriate tools may limit the ability of the system to produce more. People: Lack of skilled people limits the system. Mental models held by people can cause behavior that becomes a constraint. Policy: A written or unwritten policy prevents the system from making more.
- Каждый из нас может стать системным ограничением, если не будет расширять свои профессиональные навыки. Кен Рубин в своей книге “Essential Scrum"проводит аналогию с двумя английскими буквами “I” и “T” I - человек с глубокой но очень узкой специализацией T - человек с глубой специализацией в одной область и множеством вспомогательных навыков/квалификаций Для успешного применения практик ДевОпс, в вашей организации люди с Т-навыками должны быть в большинстве.
- Вы уже заметили, что когда Белла Безопасность стала частью команды Scrum, значительно снизилась необходимость в доработках и изменениях готового продукта. Те же принципы действуют и в реальных организациях - когда специалисты по безопасности работают вместе с разработчиками. Многих уязвимостей можно просто избежать путем тестирования на безопастность на начальных этапах разработки ПО (TDD)
- Когда Сис Админы и Релиз Инженеры входят в состав команды Скрам, разработчики получат прямой доступ к информации о том как же на самом деле работают их приложения в условиях промышленной среды, насколько легко из развертывать и поддерживать. Этот вид обратной связи важен не меньше, чем отзывы о функционале получаемые от клиентов. Таким образом ускоряется процесс получения обратной связи.
- Следующим этапом интеграции разработчиков и системных администраторов является стандартизация сред разработки и автоматизация их конфигурирования. Идея в том, чтобы вывести такие задачи на уровень самообслуживания. Чтобы любой человек в команде Скрам мог построить среду, не дожидаясь Сис Админа.
- И конечно же развертывание. Никто не любит стадать. Когда развертывания делаются редко и вручную, когда каждое из них - аврал, то появляется тенденция делать их еще реже. Получается замкнутый круг. Чтобы выбраться из этого круга, необходимо упростить развертывание, автоматизировать и тоже привести к состоянию самообслуживания. Начните с того, что попытайтесь уменьшить размер историй над которыми вы работаете. уменьшите размер ваших пакетов развертывания, автоматизируйте и увеличьте частоту развертывания. Вполне возможно что, Вам придется изменить подход к дизайну и архитектуре ваших систем, чтобы подготовиться к таким частым развертываниям. Очень интересный подход который позволяет осуществлять частые, даже неприрывные развертывания называетсы "переключение функций“ “Feature toggle” Заключается он в том, что для каждой функции над которой вы работаете создается переключатель. Это позволяет вам включать или выключать определенные функции вашего приложения, когда ПО уже работает в промышленной средe, даже на уровне конкретного пользователя. Таким образом вы можете проводить А/Б тестирование в промышленной среде, и еще сильнее ускорять процесс обратной связи с вашими клиентами.
- Есть такая теория, что для успеха любого нововведения необходимо чтобы изменение произошло Дважды: изменение действительности и изменение нашего восприятия этой действительности. Точно также с переходом на ДевОпс, важно не только ввести новый процесс, освоить новые инструменты и практики. Не менее важно, чтобы произошло изменение в культуре: уход от менталитета "мы и они", готовность к экспериментам и ошибкам, а главное понимание что мастерства можно добиться только путем повторений и практики.
- Кстати о практике. Готовы к третьему спринту? Возьмите свои карточки и обратите внимание что на обратной стороне их - наклейки с различными квалификациями. Если вы разработчик, найдите себе пару из отдела ИТ, если вы Сис Админ, найдите кого-то из команды Скрам, проведите трейнинг, обменяйтесь наклейками - расширьте свои навыки. В этом Спринте, мы с вами переходим к ДевОпс! И по-скольку теперь все кто прошел обучение Сис Админом может создавать среду, а те кто прошел обучение с Релиз Инженером может делать развертывание, дела у нас должны пойти получше. Мы даже можем попробовать делать развертывание как только закончен продукт и пакет развертывания, не дожидаясь конца Спринта! Ну как, по-экспериментируем? April 2014 - http://business.kaspersky.ru/heartbleed-doomsday/1619/ уязвимость в популярном криптографическом пакете с открытым кодом OpenSSL “Heartblead” - кровоточащее сердце
- Ну что-же, давайте сравним результаты: сколько команды произвели в последнем спринте? А сейчас мы с вами проведем "ретроспективу в аквариуме". Кто-то знаком с таким форматом? В такой ретроспективе говорить могут только тoт, кто сидит на одном из этих 5 стульев. Заняты всегда только 4 из них. На свободный стул может сеть любой из вас. При этом кто-то из тех, кто уже давно долго разговаривал должен освободить один из стульев. Попробуем?
- Мы много говорили и практиковались, у кого-нибудь еще голова кругом идет?
- Когда я готовилась к мастер классу и шерстила русскоязычные форумы про девопс, я наткнулась на такой вопрос: "А как определить мы уже Девопс или нет?" Я хотела бы чтоб каждый из вас после этого мастер класса знал, что ответить на этот вопрос.
- http://siliconrus.com/2015/01/ghost-linux/
- Всем огромное спасибо за участие, за ваши вопросы и комментарии. Очень надеюсь что вам понравилось. А уж если что-то было не так, я не виновата -
- в моей среде все работало, А это проблема сис админа